As far as my very limited understanding of the Meteor core goes, this must be a hell of a lot simpler to integrate than any other non-realtime database system out there. Not to mention SQL. Sure, the Mongo integration works (quite well actually with oplog tailing), but this seems to make all the brilliant efforts obsolete (Sorry, @glasser ).
Does anybody know of any recent community or even MDG efforts to get this flying?
Indeed, the latests developments of RethinkDB makes it a perfect fit for Meteor. RethinkDB even indicated that they have talked with MDG when they designed their API. But what makes the integration of any non-MongoDB database with meteor especially difficult lies in the 3rd principle of the platform:
Database Everywhere. You can use the same methods to access your database from the client or the server.
Which basically means that we have to re-implement a full database on the client (minimongo, miniredis, minirethink, etc.), which is non-trivial. I wrote a suggestion about that a few months ago but didn’t had a chance to work on it since then.
So you are right, the RethinkDB changefeed API drastically simplify the server driver (no more oplog+pulling fallback) but the tricky part is the wire protocol (livedata) and the client “mini” database.
Oh yes, I remember reading that discussion last year. Great write, @mquandalle !
I absolutely agree we need some form of a general API for this. Let’s just not use the term “ORM”. We’re going to start a gunfire with that. But it seems there is no way around some sort of ‘mapping’, unless we want mini-* APIS for every DB to come. On the other hand, you might loose all the DB-specific features with such a mapping. It seems to be a dilemma…
I come from MySQL, I am difficult for relation/linking/embed of many collections on Mongodb.
I thinks that the RethinkDB is good, if have Meteor package for this.
+1
Maybe this conversation should be about how support for databases get implemented.
I have always wondered if MDG’s full stack DB approach is the best way to go instead of adopting a database language like LINQ or similar that de-couples the query language from the underlying database implementation.
While not perfect, one nice benefit of this approach might be that an app could target different backends based on unique repository features.
You might also rethink whether the client and server DBs necessarily have to be the same. Not sure if that would be good or bad.
I know I am glossing over some serious implementation details (so don’t shoot me) but I guess the question is “where do you want the complexity?”
Treating each DB as a full stack affair vs separating the DB implementation from the backend repository.
I sense some urgency from the community for MDG to support DBs other than Mongo and Redis, something relational. MySql, Sql Server, Oracle etc.
Was just pondering how building a separate full stack for each would be faster or easier to get to this end game vs building this common query language translation layer.
Yes I believe we want to “de-couples the query language from the underlying database implementation”, and in a way this is already what we do. Indeed we use the same query language on the client and the server, but with different drivers/backends (in-memory vs polling vs oplog). Note that the query language we use in meteor is similar to mongoDB but not identical, for instance .fetch() or .observe() methods of a cursor do not exists in mongoDB. With that in mind, one approach we could take to integrate RethinkDB would be to translate minimongo queries into rql on the server, and to keep using minimongo on the client.
The question is more “What query language should we use?”. Interfacing the current query language (that’s is heavily inspired by mongoDB) to anything else (redis, rethinkdb, sqllite, neo4j, etc.), is somewhat tricky. But I’m not sure what the desired language would be here.
Exactly a month, RethinkDB 2.0 realtime capabilities has been released and would fit perfectly with Meteor! It’s probably a good timing for getting it works if anyone is interested. https://news.ycombinator.com/item?id=9374927
Change-feeds is what drives their realtime data pushes and it only works on certain queries. Changefeeds has been upgraded to support some more kinds of queries but JOINS is still in the works.
).
