I am thinking of the implications that not allowing m/? outside an m/sp or m/ap: So my example is that datahike library starts using missionary internally because it has a lot of benefits. This means all internal functions return missionary tasks. It is only logical that datahikes api would return missionary tasks. Now users of datahike who are not missionary users would want a blocking api. Datahike could do so by wrapping m/? around it's task api. This should still work. Now the problem would arise when a library that uses datahike with the blocking api is used by an app that on it's own uses missionary. Then problems would happen. @leonoel is this about correct?
Excuse me for interfering, but I do not see any Missionary-related code in Datahike repo... Can you give me any direction? If it would implement seamless integration into Missionary tasks/flows, it will totally fit my current project stack. I am looking forward to take a look
@sasha_bogdanov_dev I was giving just an example. However, the author of datahike has communicated his intention to do so in this chat a few days ago.
Okay. Will see π
hey, i had this discussion with @hoertlehner recently.
datahike's transact! uses a completable future now, which works inside missionary flows for me. it currently only exposes a core.async promise-chan, not yet a missionary specific way to react though (so you need to map to a flow): https://github.com/replikativ/datahike/blob/main/src/datahike/tools.cljc#L76
the query engine is currently fully synchronous, mostly for comptability, but also for performance reasons
so that should not be a problem, i think
i am happy to make direct adjustments if there are problems with using datahike as is for somebody
i was discussing building a new reactive query engine with differential dataflow for datahike with missionary with @hoertlehner
on a single machine connections of datahike also support just watching like an atom, so you can already construct reactive flows right away
this does not work for distributed datahike yet
(you could do manual polling though)
@sasha_bogdanov_dev what do you need to use it?
Itβs fine. I can do it manually for sure.
> @leonoel is this about correct?
Yes, but indirect blocking calls from missionary code is an antipattern anyway. If the async API is available via tasks or flows there is really no reason to use the m/? wrapper
So on other words: one use of m/? outside is ok. But then this functions are taboo to be used inside missionary m/sp or m/ap.