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.
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?
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.
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.
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:
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.
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.
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)?
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!
28 comments
[ 2.7 ms ] story [ 75.1 ms ] threadalex @ rethinkdb
Am I wrong in thinking that?
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)
Nonetheless, I must agree that focusing on the DB itself is for the best. Keep up the excellent work.
Nashorn would let you get rid of the Javascript Protobufs implementation and use the Java library from Google, among other potential optimizations.
--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....
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.
https://github.com/rethinkdb/rethinkdb/wiki/ReQL-changes-in-...
I don't see it on there.
--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.
--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.
https://gist.github.com/sibblegp/cfe88c672bf613eaba42
Managed to replicate it with ease :(
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.
Sorry for the temporary regression -- we promise we'll get the numbers back up!