RethinkDB: An open-source distributed database built with love over three years

Post by coffeemug » Mon, Nov 12, 2012, 3:01 PM UTC

muhqu wrote: post #240

coffeemug wrote: post #225

Earlier quoted context omitted.

My point was that you don't have to do that with rethink because the entire query gets executed on the server. You don't have to take the value down to the client, make the change, and then send it back. The entire update gets evaluated on the server and the server handles atomicity in various ways (depending on the query).

Do you think something like the following should work with RethinkDB? r.table('foo') .get(5) .update({ '_rev': r.branch(r['_rev'] == 5, r('_rev').add(1), r.error("invalid revision") ), 'name': "awesome name" }) the basic idea is that `name` should be update to "awesome name" and `_rev` should be incremented by 1, but only if `_rev` is 5, otherwise an "invalid revision" error should be thrown.

Post by skeletonjelly » Mon, Nov 12, 2012, 9:45 PM UTC

whyleyc wrote: post #200

jacquesm wrote: post #46

Earlier quoted context omitted.

Releasing a project like this means working very hard for a long time without anybody patting you on the back saying you're doing a good job. It's exhausting, a labour of love. Get it now?

I reckon $1.2 million in funding helped soften the pain :)

Post by kemiller » Tue, Nov 13, 2012, 7:03 PM UTC

rdtsc wrote: post #163

kemiller wrote: post #90

Earlier quoted context omitted.

But there's no standard way of representing the dates as strings, or indicating that this field here is a date and not a string that happens to look like one, so nothing can rely on what you do. You can represent literally anything with a string, but you lose type information when you do.

There is a standard for representing string (see sibling comment) and your type information is the field name. So you know your document has a type if you give it a d_type field for example and then based on that you know your tstamp field is the date.

Post by alphadogg » Fri, Nov 16, 2012, 3:23 PM UTC

dbuxton wrote: post #96

shawn-butler wrote: post #83

Earlier quoted context omitted.

While technically correct I assume the parent was referring to hstore [0] which has both GIST and GIN indexes as well as btree and hash for equality. With some simple formatting functions (its just json after all) it's sixes to me. [0] http://www.postgresql.org/docs/9.2/static/hstore.html

hstore is great, I won't hear a word against it, but it doesn't deal with complex nested objects like JSON can (I would love to be wrong about this) - it's just a key/value store with indexing of the objects inside.