41–50 of 51 posts
The post says: >We'd like to make more complex queries available via realtime push. In particular, efficient realtime push implementations for the eq_join command and map/reduce are fairly complex, and aren't making it into 1.16. Will innerJoin be supported in 1.16?
There is currently no push implementation for joins. That's coming in the next few releases.
The article discusses how RethinkDB differs from "realtime sync services" such as Pusher, PubNub, and Firebase. While comparing against Firebase makes sense because it's an alternative database, I see Pusher and PubNub (and similar pubsub services, such as Fanout) as being complementary to RethinkDB.
Article also points out that you can't get a "realtime incremental feed", but the example they provide is quite easy and similar in Firebase by using orderBy() and limit() to return an updating query. As someone who has built lots of apps using Firebase, I can appreciate the first point about limited querying capabilities; this has been my number 1 painpoint from Firebase. I'd imagine the second point can be somewhat…
On the one hand this is pretty awesome - just as I expect from the rethinkdb team - but on the other hand I'm wondering that while they are removing serious pain points from web development where are the startups that use these as a competitive advantage? Is RethinkDB understood?
Earlier quoted context omitted.
The basic architecture is browser web server database. When the web browser connects to the web server, the web server opens a database feed. When the database pushes changes to the web server, the web server pushes them to the browser via socket.io.
Is this not already possible with MongoDB, using something like mongooses post('save') [1]? [1] http://mongoosejs.com/docs/middleware.html
Baking feeds into the database should dramatically simplify the amount of required work.
Earlier quoted context omitted.
You could probably get a poor's man version of this by setting up materialized views, a trigger on those views, and then write code in the trigger that pushes updates onto a queueing system. It wouldn't be quite as convenient, but would probably accomplish what you want in many situations.
This exists: https://github.com/omniti-labs/pg_amqp
How does the general performance of rethinkdb compare to http://www.tokutek.com/tokumx-for-mongodb/ ?
I wonder if it would be feasible to add this sort of real-time feed to a conventional RDBMS like PostgreSQL. This feature would be quite useful for at least one of my projects, but I'm not sure I want to give up a mature SQL-based DBMS for something relatively unproven like RethinkDB.
You could probably get a poor's man version of this by setting up materialized views, a trigger on those views, and then write code in the trigger that pushes updates onto a queueing system. It wouldn't be quite as convenient, but would probably accomplish what you want in many situations.
Earlier quoted context omitted.
You could probably get a poor's man version of this by setting up materialized views, a trigger on those views, and then write code in the trigger that pushes updates onto a queueing system. It wouldn't be quite as convenient, but would probably accomplish what you want in many situations.
This exists: https://github.com/omniti-labs/pg_amqp