RethinkDB 1.4 is out: better protocol, drivers, data explorer history | Hacker News Reader

RethinkDB 1.4 is out: better protocol, drivers, data explorer history

rethinkdb.com

93 pointsmglukhovsky28 comments

Open articleView on HN

Refactoring code for 1.4 in Python. Here are the fixes I've had to make so far (so everyone can reference):

--Adjust imports

Change: "from rethinkdb import r" To: "import rethinkdb as r"

--No more connection.run()

Change all your connection.run() to .run(connection)

For instance:

connection.run(r.db('test_db').table_create('test_table'))

becomes

r.db('test_db').table_create('test_table').run(connection)

--No more global connections

This one sucks IMHO. Took more than I'd like to refactor (still in progress). You have to explicitly pass a connection to every run() command. So this:

r.table('test_table').run()

becomes

r.table('test_table').run(C)

where C is a declared connection.

More notes as I find them....

Thanks for the notes gsibble, please let us know anywhere where we can make the docs more clear, especially anywhere the behavior has changed since 1.3. We appreciate your patience with the breaking changes.

As for the changes to `connection.run` and `query.run` please note that in the Python driver you can call `.repl()` on any newly created connection to set that connection as a global default. This should replicate the old behavior.

We decided that doing this by default was unsafe as it relied on global state modified any time a new connection is opened. Even so, we appreciate the convenience and kept the behavior in the form of the `.repl()` for when you're trying out RethinkDB in a simple script (or the Python REPL) that only creates one connection and doesn't use threads.

Oh damn. Already halfway through refactoring. Can you update the change docs to note that?

https://github.com/rethinkdb/rethinkdb/wiki/ReQL-changes-in-...

I don't see it on there.

Sorry -- just updated the doc.

No worries. I should have looked for it!

Another one:

--Remove primary key definition from .get()

No more primary key name is needed as a 2nd argument (and in fact breaks if you pass it). Just delete it.

And one more:

--List of RDB objects is now a cursor, not a list

Some iterations (notably for loops in jinja2) don't iterate properly. Need to pass them a real list by calling list() on the cursor.

How do they fail. Calling list() on cursor objects could be a really bad idea if they contain a lot of data since it will cause it all to be loaded in to memory.

Nothing shows up when I use an iterator for loop in jinja2. Not sure why. Turning it into a list fixes it.

This made sense. Cursors used to behave as lists implicitly, now we just make it explicit to make it very clear what's happening.

Please don't get me wrong, but are there any details as to when RethinkDB will get its old speed back (before the addition of the cluster layer)?

Because currently it seems that even for instance MySQL mostly performs a lot faster than RethinkDB and that makes me kinda sad, because I would really like to try this in a production environment.

Yes -- we still have to work out some core features (such as secondary indexes and a few ReQL improvements). After that, it will all be about performance, performance, performance. We'll do a lot of performance optimization most likely in 1.7, which will be around end of June (about the time when Rethink will be labeled ready for production use).

Sorry for the temporary regression -- we promise we'll get the numbers back up!

Could you guys please look at why I'm getting an error deep inside protocol buffers?

https://gist.github.com/sibblegp/cfe88c672bf613eaba42

Managed to replicate it with ease :(

I opened a github issue for this https://github.com/rethinkdb/rethinkdb/issues/495. Could you please comment there on how you got this error (i.e. what version of the server and client you're running, and what data is in the database)?

Ok, some more info on the issue -- could you please follow up there?

Thanks guys! Keep up the awesome work!

Still no official Java drivers ?

Hi, I'm slava@rethink, I'm ultimately responsible for what goes into the product and when.

We'd love to get more drivers in (and the new, much simpler protocol we just shipped will go a long way towards community-supported drivers). But we decided that having a high quality product for the people using the drivers we do support is currently much more important than having wider driver support. Once we iron out a few more quirks in the core product, adding more drivers will be really easy. But until then, more drivers will help fewer people than improvements to the core language and product.

(BTW, getting Rethink to JVM users is something I'm personally very interested in, in my case because of Clojure, but Java programmers will also benefit)

I must say that I am very glad to read this, since I am also looking forward to deploy RethinkDB alongside Clojure (or Erlang, but I fear that will have to wait for quite a while).

Nonetheless, I must agree that focusing on the DB itself is for the best. Keep up the excellent work.

I've got a branch of Nashorn (Oracle's Javascript runtime which will be included in OpenJDK 8) modified to build with Java 7. It passes 100% of the ECMA-262 test suite and you can grab it at http://github.com/furosys/nashorn

Nashorn would let you get rid of the Javascript Protobufs implementation and use the Java library from Google, among other potential optimizations.

Thanks, this looks great, will look into it!

I understand, you focus more on the startup kind of customers for now.

Still not, but the new protobuf spec (and rewritten existing drivers) should actually make it pretty easy to get one. I've also heard of a couple of people working on Java and Scala drivers (they were following the new protobuf spec branch), but I don't know the status.

alex @ rethinkdb

So it won't be official and it may break on any server update or lag in features depending on the maintainer boredom. Too bad, your db seems really nice :)

There's no decision made on this yet. So far, as @coffeemug explained in the previous comment we decided to focus all our efforts on improving the server and getting it closer to "production ready" state, instead of spreading our resources thin and creating a lot of drivers that are not as good as we'd want them to be. The initial protobuf spec was complicated and building drivers on top of it would have required a lot of effort (effort that we thought would be better used to improve the spec and the query language, things that everyone would benefit).

All of that work improving the spec and the query language should make it that much easier to make a decent driver. I'd say around the time of it being "production ready" as you put it should be where you have a version that keeps the same protocol so that drivers can be written and not have to be updated for every bug fix?

Am I wrong in thinking that?

No, you're absolutely right -- when we mark Rethink as production-ready, we'll also freeze the APIs and ABIs and will be much more careful about breaking things for people.

Is there transactional noSQL database?

Reply on news.ycombinator.com