I use and prefer congomongo, and am happy with its current state. It's lightweight and does what I want it to do.
I've looked at monger a couple of times, and felt it was more involved than I wanted. For example, I was turned off by the need to manually create object IDs as part of creating records. I like how congomongo does it for me. Maybe overhauling congomongo is not the way to go. Maybe let monger occupy the more complex niche, and just do the minimum updates to congomongo to keep it current with evolving java and mongo apis, keeping congomongo nice and simple. --Mark On Wed, Feb 26, 2014 at 3:04 PM, Sean Corfield <s...@corfield.org> wrote: > (this is a variant of a discussion I started on the congomongo-dev mailing > list a while back) > > Do you use MongoDB with Clojure? > > Which library do you use? > > I seem to have become the de facto primary maintainer for CongoMongo now - > I gather most other maintainers are not currently using MongoDB (or are > just happy with the status quo). > > Having gone through the recent major overhaul of java.jdbc, I'd like to > see something similar for CongoMongo and with the new MongoDB driver > version (3.x) bringing API changes, it seems like a good time to discuss > the direction for CongoMongo... > > I'd like to see CongoMongo's API completely overhauled, to remove > dependencies on dynamic global variables etc, so this would be introduce a > new API, and deprecate the old API. > > I'd also like to see a congomongo organization on Github for managing > CongoMongo going forward, much as exists with clj-time. So maybe it's time > to think about a break with "tradition" and fork the project into a new > location and build the new API there instead? Or perhaps even a ground-up > rewrite under a new name? > > The other popular MongoDB client library is Monger, but it's also > primarily an "imperative" API with globally managed state (connect! set-db! > disconnect! etc) although it provides a much richer composable DSL and > vastly superior documentation - and it provides a secondary API that allows > you to pass in the db handle everywhere but its definitely not as clean / > complete as the primary API. > > I've spent some time at work on a spike to convert our application from > CongoMongo to Monger and there are pros and cons to Monger's API - I'm > finding I have to rely more on being closer to the metal in terms of the > Java API which is sometimes a good thing and sometimes not. We have hit a > couple of roadblocks that I'm discussing with Michael / ClojureWerkz which > prevent us going all the way with Monger. > > At this point I'm not sure which way World Singles will go. I'm not sure I > have the heart for a complete rewrite of CongoMongo but there are parts of > Monger I'm not happy with either. Michael / ClojureWerkz have been very > receptive to suggestions and pull requests so part of me feels like that's > a better use of my time - but if folks are genuinely interested in a new > version of CongoMongo, I could be persuaded to do that instead. > > What are your thoughts on this? > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
