monger icon indicating copy to clipboard operation
monger copied to clipboard

Async operations in the API

Open michaelklishin opened this issue 9 years ago • 9 comments

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.

michaelklishin avatar Oct 20 '15 08:10 michaelklishin

Any update ?

Elyahou avatar Aug 15 '16 14:08 Elyahou

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.

michaelklishin avatar Aug 15 '16 14:08 michaelklishin

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 avatar Apr 19 '17 22:04 robert-m-johnson

@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.

michaelklishin avatar Apr 19 '17 22:04 michaelklishin

Apologies, I thought you were talking about about a clojure.core future.

robert-m-johnson avatar Apr 19 '17 22:04 robert-m-johnson

@robert-m-johnson Clojure futures are quite literally j.u.c. futures.

michaelklishin avatar Apr 19 '17 22:04 michaelklishin

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.

michaelklishin avatar Apr 19 '17 22:04 michaelklishin

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.

robert-m-johnson avatar Apr 19 '17 22:04 robert-m-johnson

Noted.

michaelklishin avatar Apr 19 '17 23:04 michaelklishin