I think most folks will be aware that Apache CouchDB is an open source JSON data store. Apache Couch DB 2.0 has a query API that is similar like Mongo’s, contributed by Cloudant and been available on Cloudant DBaas for quite a while now.
The package simply reuses minimongo on the client side. The readme of the package both on Atmosphere and in github, document how you can use the module and its API.
We would love to get your feedback and see what works well and what doesn’t. We do plan to maintain it and keep it up-to-date maybe build more features – your input can help shape the future of this package. Please feel to open any issues, feature request in the github repo
I was wondering if you ran into anything on your journey of implementing a new database driver for Meteor that was confusing, poorly documented, or could be improved.
thanks for the links about postgres module. Cool about that. I did notice that a few days back and was intent on going through it. From your link i noticed that you have this
’# Fake MONGO_URL so that Meteor doesn’t start MongoDB for us
export MONGO_URL=“nope”
'
If you turn off MONGO, how is the base housekeeping stuff that meteor persists in Mongo handled ? Also when one uses the accounts feature of meteor, are you able to get that pushed to postgres ? If yes, i am curious to learn how you do that
I briefly looked at the source code and looks like, a lot of it was a copy-paste of the mongo observe driver. I also saw lots of comments in a form of “mario: this should be rewritten …”. Which makes me doubt the completeness of the implementation. Is there any explanation on how the latency compensation was implemented?
hey slava,
it is the meteor mongo module code only, with just the relevant parts changed/tweaked for CouchDB. That is and was the idea to start with, the reason being both are JSON stores, with a ‘similar’ query syntax, both have mechanisms to listen to changes in the DB (oplog/_changes feed). The tweaks in the code were around a) the _changes feed in CouchDB is per database… (i treated 1 mongocollection=1 couchDB database), whereas mongo’s oplog is across DB’s b) CouchDB uses a change sequence # that is a opaque string, so one cannot do <= comparisons like on Mongo’s oplog timestamp… therefore the waitUntilCaughtup logic had to be different. c) update API signature is different of course since CouchDB does not have update operators.
I haven’t put in the transforms feature (looks easy enough) and similarly EJSON, since i would need more understanding the latter and how it would relate to CouchDB. Thanks about the feedback about the ‘mario comments’… i relooked via grep, 2 are from my early days of hacking to understand the whole system and to be cleaned up (next release thanks…) all the remaining are valid notes of my changes related to the 3 CouchDB differences i mentioned above and the other 2 features that i have mentioned that i kept out.
Given my explanation above of it being the mongo module code only with just tweaks for CouchDB difference, if you could be specific about the latency compensation part in the code, i can probably better answer.
good question. That was one idea when i started, but as i got to understand the mongo and minimongo modules in general, i realized code in minimongo was also about detecting whether an update affects any open cursor and things like that, which i would still need and then write code to integrate. Further i was not going to be able to use pouch’s direct replication to CouchDB server here, since that would bypass the entire meteor middleware.
“since that would bypass the entire meteor middleware.” … In that case, if one combined your goodies with those inside of PouchDB, how close would one come to replacing the DDP and WebSockets and need for sticky sessions and ending up with a better middleware? If so, would it not even make sense to throw ElasticSearch into the mix, where all of the searching and search related data retrieval would be from ElasticSearch, while all of the change would be from CouchDB. That way, one could easily put any database behind ElasticSearch, as long as that database could some way provide a feed of its changes.