monger
monger copied to clipboard
Async operations in the API
What was originally requested in #94. This can be done with deeper integration of the new lower-level Java client primitives available in MongoDB Java client 3.x. core.async
will not be considered as it is a substantial dependency to support going forward, and is maintained in a way that I strongly dislike.
One key question is: should the API use futures or callbacks? The former makes a lot more sense for Clojure in my opinion.
Any update ?
No one is working on this at the moment to my knowledge. Feel free to begin exploring what the new API might look like with futures.
RE futures vs callbacks - are you sure you mean futures rather than promises? Either way, I think that at a minimum callbacks ought to be supported since they give the most flexibility; this leaves the client free to decide whether they want to deliver the result to a promise
, or a core.async
channel, or whatever.
@robert-m-johnson futures is a term for asynchronous operations that's been around since at least ~ 2004 when they appeared in JDK 5. Promises is a term largely popularized by a certain community that prides themselves on not knowing anything about Java or java.util.concurrent. They are not meaningfully different if you ask me, in Clojure or otherwise.
Apologies, I thought you were talking about about a clojure.core
future
.
@robert-m-johnson Clojure futures are quite literally j.u.c. futures.
I am not a fan of callbacks and I don't buy into the argument that callbacks somehow provide more flexibility, however, that's largely irrelevant. At this point it's primarily a matter of what's easier (realistic) with the new-ish MongoDB Java client API. I have little time to devote to this project and the fewer complex features we burden ourselves and our users with, the better. So going with the flow of the Java client API makes most sense.
OK, being more specific, I was talking about the function clojure.core/future
as opposed to clojure.core/promise
. My concern was simply that the former potentially kicks off another thread, whereas it's clear that promise
does not.
Noted.