231–240 of 247 posts
Earlier quoted context omitted.
Maybe one that wants to keep working through high inflation scenarios. (But what financial software is running on a NoSQL database?)
I think perhaps you replied to the wrong comment? I didn't pose the question "what financial app needs >53 bits of precision?"
Earlier quoted context omitted.
I find I prefer SQLAlchemy's Table.query.filter(Table.bar > 5) to a lambda that gets compiled to an AST in an odd way.
You can do that too: r.table('foo').filter(r['bar'] > 5) The use of r in filter is getting the attribute bar of the row.
Have you found that there are useful expressions that are awkward to express without the lambda trick?
Earlier quoted context omitted.
You can do that too: r.table('foo').filter(r['bar'] > 5) The use of r in filter is getting the attribute bar of the row.
That's pretty cool. Have you found that there are useful expressions that are awkward to express without the lambda trick?
Lambda syntax is really nice too, I actually prefer it for writing queries.
Earlier quoted context omitted.
That's pretty cool. Have you found that there are useful expressions that are awkward to express without the lambda trick?
Lambda is necessary because when you do nested subqueries, saying r['x'] is ambiguous and can cause all sorts of unpleasantness. So, if you use nested queries, the server rejects the implicit syntax and requires the use of lambda. Lambda syntax is really nice too, I actually prefer it for writing queries.
Again taking an example from SQLAlchemy, you can explicitly make a subquery, and then reference it instead of the original Table. A binding more like SQLAlchemy can probably written for RethinkDB.
I am very excited about this. The RethinkDB team is rock-solid and the market is only going to get bigger. I particularly like the perspective of an easy onramp to get started, knowing that I will never have to leave because of scale or reliability. Please, please give me a SQL adapter! My marketing team needs SQL. My business app developers need SQL. Give them an adapter and I will get them to use RethinkDB - knowin…
Is the package up on Ubuntu PPA already ? it seems that the installation instructions use the ppa, but apt-get doesn't find the package. edit: Indeed, my architecture i386 doesn't match the only available amd64 binaries. Thanks
The package is up. Which ubuntu version are you using? We support 11.04 and above. Anything less than that is missing some kernel features we use. EDIT: the main thing missing from earlier ubuntu versions is TCP_USER_TIMEOUT. We can work around it in the server, but we haven't done it yet.
Earlier quoted context omitted.
I think the atomicity model here works like a transaction on the whole document, where all the changes to the attributes of a document are updated all at once. The scenario I described has to do with read-consistency, where the value read by a client should not be changed during the time of the read and the time of the update. The usual way of handling it was to take a write lock for the duration to prevent update fr…
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).
E.g. the client reads a value, displays to the user, gets input from the user which is based on the old value, and stores the updated value. If another user doing the same thing has already changed it, the client would like to know that and let the user retry, with the new current value.
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).
That approach would only work if all the logic to compute the update can be expressed in the update query. It will break down if the read-eval-update cycle involves the client. There are many scenarios involved the clients. E.g. the client reads a value, displays to the user, gets input from the user which is based on the old value, and stores the updated value. If another user doing the same thing has already change…
r.table('foo').get(5).update({ 'bar': r.branch(r['baz'] == 0, "foo", r.error("invalid baz!"))})
Earlier quoted context omitted.
I think the atomicity model here works like a transaction on the whole document, where all the changes to the attributes of a document are updated all at once. The scenario I described has to do with read-consistency, where the value read by a client should not be changed during the time of the read and the time of the update. The usual way of handling it was to take a write lock for the duration to prevent update fr…
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).
r.table('foo')
.get(5)
.update({
'_rev': r.branch(r['_rev'] == 5,
r('_rev').add(1),
r.error("invalid revision")
),
'name': "awesome name"
})