RethinkDB Gems

After idling in the RethinkDB freenode IRC chat, I think I’m going to start a collection of very good Q/A that I see:

<dubcanada> One more question, is there an easy way to duplicate all the content in the DB
<dubcanada> I’m trying to fill it up with a ton of records for testing but it seems to be taking forever lol
<AtnNn> dubcanada: you can do something like r.table(‘foo’).insert(r.table(‘foo’).without(‘id’))

Search for documents without field:

<nicklovescode> what’s the best way to search for documents without a field? I tried .filter({ foo: undefined }) but that got an error
<srh_> nicklovescode: you can use .filter(r.row.hasFields(‘foo’).not())

How to implement failover:

20:20 <bg__> i also have a question regarding failovers
20:22 <bg__> until #223 is resolved, is there a suggestion regarding how I should handle failovers? Meaning, if i have services that are using my rethinkdb, and I have tables that have replicas, how can I ensure I’m not trafficing requests to an unresponsive node?
20:23 <neumino> You need to have a connection opened to the server
20:23 <neumino> If the connection is dropped
20:23 <neumino> You can try to connect to another server
20:23 <bg__> okay. so lets say i have web1 and web2 which are nodejs web servers
20:24 <bg__> and they handle requests that require them connecting to rethinkdb and reading from one table
20:24 <bg__> and because im afraid of one serving dying in the middle of the night, i have two rethinkdb servers, rethink1 and rethink2
20:25 <bg__> what connection string do I use to have web1 and web2 connect to rethink1 and rethink2 that protects me if rethink1 or rethink 2 goes down
20:25 <bg__> i only have web1 and rethink1 right now. web1 explicitly connects to rethink1
20:25 <bg__> but I’m reaching a point where that is not safe
20:26 <neumino> Hum
20:26 <bg__> did that make sense?
20:27 <neumino> bg__, if the master of your table fails, you won’t be able to write until you declare the master dead
20:27 <neumino> We currently don’t have a nice way to do it, but the coreos folks did it that way:
20:27 <neumino> They fetch `http://server:8080/ajax`
20:27 <neumino> They fetch `http://server:8080/ajax/issues`
20:27 <neumino> If there is a dead machine
20:28 <neumino> They start a script that is going to kill it using `rethinkdb admin`
20:29 <bg__> ah ha.
20:29 <bg__> i did not know about those two end points
20:30 <bg__> i was going to have a script that polled the server
20:30 <bg__> i just wasnt sure what endpoint to use
20:30 <bg__> those seem to do the trick
20:31 <bg__> thanks@!
20:31 <bg__> is there any documentation about that?
20:32 <neumino> Hum not really :/
20:32 <neumino> If you start `rethinkdb admin`
20:32 <neumino> And then send `help`, you should get the docs for `rethinkdb admin`
20:32 <neumino> For `ajax/issues`, there is no doc for now
20:33 <neumino> Try to kill a server and you will see the error you get
20:33 <bg__> i meant /ajax and /ajax/issues
20:33 <neumino> It’s something like “DEAD_MACHINE” I think
20:33 <neumino> Oh
20:33 <bg__> both seem very important to someone trying to use rethinkdb as a distributed system
20:33 <bg__> getting around this isn’t difficult now that i know about those
20:42 <bg__> just out of curiousity, when you say ‘the way the coreos folks did it’ what do you mean?
20:45 <neumino> Oh, the engineers at coreos needed to set up a kind of failover with rethinkdb
20:45 <neumino> and that’s what they did
20:45 <neumino> It’s kind of the only solution now ^^
20:45 <neumino> (well you could skip `rethinkdb admin` and craft post request like the web interface do
20:46 <bg__> oh, got it.
20:46 <bg__> its a great solution for now.

Performance filtering:

<thelinuxlich> something that is bugging me these days
<thelinuxlich> is it more performant to do a filter before or after a eqJoin ?
<AtnNn> if your filter only needs fields from the left table, it is better to filter before the join
<AtnNn> thelinuxlich: ^
<thelinuxlich> AtnNn: what if it uses a single field on the right side, should I filter before eqJoin on the left and after eqJoin on the right?
<AtnNn> yes, if you can independently filter from both tables
<thelinuxlich> this is a bit confusing