7 ms·

RethinkDB 1.3 is out, now available on OS X

178 points by coffeemug 14y ago

MatthewPhillips 14y ago
This is an example of an excellent website for a developer tool. Even the blogpost contains a hello world example in the header. The front page contains everything you need to know in just a couple of sections.
eberfreitas 14y ago
Is anyone over here using it? What is your impressions?
- StavrosK 14y ago
  I used it for a bit, my first impression was very good, if buggy. The team is very responsive and extremely accommodating, and I'm hoping they make a very solid database. The featureset looks great, and the admin interface is fantastic. I would definitely recommend giving it a try.
  - m0th87 14y ago
    Could you expand on the buginess? Was it aesthetic issues, or did you ever face problems like data corruption?
    - jdoliner 14y ago
      RethinkDB is still very young software and will take some time to mature. The worst issues that we had during the last release cycle did result in data corruption, one due to a bug in our code. Another due to a filesystem we weren't expecting (which we still consider to be a bug in our code.) Right now we can't recommend RethinkDB for production ready code but we're working very hard to get it to that point. Part of this is beefing up our internal testing system which we've made a big push on during the last release cycle. Part of that is fixing all of the bugs that users submit until they stop finding serious ones.
      - StavrosK 14y ago
        What jdoliner said. A few were cosmetic, but I think I experienced some data corruption as well (it was a test dataset). The team was extremely responsive and fixed the bugs in a few hours, and RethinkDB is clearly marked on their website as still an alpha, so I can't blame them. I'm sure it will be a fantastic product when it matures, and I can't wait for a stable release so I can try it out.
      - jbellis 14y ago
        Maybe I'm just an old fart, but I think it's less misleading to label "not production ready" releases with a 0.x.
        coffeemug 14y ago
        Oh, that's very true. We used an internal versioning scheme and it became exceedingly difficult to change all the repo tags, internal references, etc. so we decided to just bite the bullet and use the same scheme publicly and privately. I wouldn't have done this if we could go back in time, but you know what they say about hindsight :)
bjourne 14y ago
It's great to see all these new ideas in the db arena. But one thing I don't understand at all is why they diss the idea of having data integrity. Am I the only developer who actually likes working with relational data and do not think of a schema as a straight-jacket? Am I the only one getting burnt by MySQL and SQLite playing loose with types and silently coercing data almost randomly? Check constraints are also great and has saved my ass so many times. It's so much easier to debug a problem when the crash occurs when you are inserting the data than in a wrong calculation much further down the line. Postgres for example, allows you to create regular expression constraints which you could use to ensure that a text column only contains a valid variable name. Exclusion constraints are even better, if you have a table with allocations (date ranges, integer ranges, etc) you can check so that none of the allocations overlap. Plus about a million other ways you can constrain your data. That's the killer features for me. They have helped me debug problems so many times that I consider them almost essential to writing good web applications. So why does almost all new database projects seem to neglect them?
- m0th87 14y ago
  Schemas have saved my ass a million times too, but schema migrations are a pain. I'd love a database that's loose with types by default, but allows you to add declarative specifications for types. Documents are checked at insert/update time, but otherwise the specifications play no role in how the data is stored. That way you get schemas, but only when you need them. And migrations don't require heavy collection-wide locking; instead, you just change the constraints you enforce and lazily update old documents. Postgres does to an extent with CHECK constraints, but you still have to do an ALTER TABLE if you change the underlying type of a column.
  - petergeoghegan 14y ago
    Yes, you still have to do an ALTER TABLE to change the type of a column within Postgres, because, well, that's just how it's done. This does not necessarily mean that the table will be rewritten, which I assume is what you're concerned about. See this item from the Postgres 9.2 release notes: Reduce need to rebuild tables and indexes for certain ALTER TABLE ... ALTER COLUMN TYPE operations (Noah Misch) Increasing the length limit for a varchar or varbit column, or removing the limit altogether, no longer requires a table rewrite. Similarly, increasing the allowable precision of a numeric column, or changing a column from constrained numeric to unconstrained numeric, no longer requires a table rewrite. Table rewrites are also avoided in similar cases involving the interval, timestamp, and timestamptz types.
ksev 14y ago
Does this include the new wire format? That was talked about here: http://www.rethinkdb.com/blog/rethinkdb-wire-protocol-call-for-comments/ http://www.rethinkdb.com/blog/rethinkdb-wire-protocol-call-f... I'm itching to write a toy client in clojure.
- coffeemug 14y ago
  No, this doesn't include the wire protocol updates yet. That's slated for 1.4 -- sorry!
  - ksev 14y ago
    Alright, gives me more time to nail down a nice query DSL :) Nice to see OSX support, simplifies development quite a bit for us mac users.
SnowLprd 14y ago
I commend the RethinkDB folks for supporting Mac OS X explicitly. However, the .pkg installer, while handy for folks that prefer that installation method, installs to /usr/bin/ and /usr/share/ -- areas that are traditionally reserved for system tools provided by Apple. Sure, the DMG also contains an uninstall-rethinkdb.sh script, but I'm still left quite unwilling to kick the RethinkDB tires on my primary Mac workstation. A better method, in my opinion, would be for the RethinkDB devs to contribute a Homebrew formula. That way everything would be installed into /usr/local/ by default, and updates would be a quick "brew upgrade rethinkdb" away. Am I the only one who would prefer that? UPDATE: It seems they had originally planned on a Homebrew formula but thought the .pkg format was better. Clearly, I disagree with that. Want to offer both? Awesome. But if you're going to pick one or the other, I think Homebrew is the vastly superior method. More here: https://github.com/rethinkdb/rethinkdb/issues/5 https://github.com/rethinkdb/rethinkdb/issues/5
- coffeemug 14y ago
  The reason we did that is because /usr/local/bin isn't on the default path on many OS X systems, and we didn't want the installer to modify the user's PATH. The thing about Homebrew is that it's great once you have it, but the user experience of actually installing it can be quite a pain, and we didn't want users who don't have it to have to go through the trouble. That being said, I still think it would be great to contribute a Homebrew formula.
  - SnowLprd 14y ago
    Regarding the first point, which OS X systems are you referring to? The default PATH on Mountain Lion definitely contains /usr/local/bin, as you can see here: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin With respect, I don't share the view that installing Homebrew is a pain. Even the most inexperienced would-be developer can follow the very simple guide I (very coincidentally) posted yesterday: http://hackercodex.com/guide/mac-osx-mountain-lion-10.8-configuration/ http://hackercodex.com/guide/mac-osx-mountain-lion-10.8-conf... But it seems you guys are amenable to offering both the .pkg installer and a Homebrew formula, which would be great. :^)
themgt 14y ago
http://rethinkdb.a.pogoapp.com/ http://rethinkdb.a.pogoapp.com/ - our demo has been updated to 1.3.1
DeepDuh 14y ago
I can't find information on how (or whether) you handle users. Is there some built-in per-document read/write lock based on user access for example? This is the most important feature I miss in CouchDB.
- coffeemug 14y ago
  Do you mean permissions (i.e. granting access to tables based on authentication)? If so, Rethink doesn't have that yet, but it's definitely on the list.
gummydude 14y ago
can't wait for final golang driver, kudos for listening.
- coffeemug 14y ago
  You might want to check out community one for now -- https://github.com/christopherhesse/rethinkgo https://github.com/christopherhesse/rethinkgo (perhaps even contribute -- hint hint)
  - cshesse 14y ago
    This driver attempts to match the official drivers as closely as is reasonable. It has almost all of the functionality of the official drivers now, but won't have a stable-ish API or actual tests until the end of December. Let me know if you have any feedback, this is the first Go language library that I have built.

178 points by coffeemug 14y ago

This is an example of an excellent website for a developer tool. Even the blogpost contains a hello world example in the header. The front page contains everything you need to know in just a couple of sections.

eberfreitas 14y ago

Is anyone over here using it? What is your impressions?

StavrosK 14y ago
I used it for a bit, my first impression was very good, if buggy. The team is very responsive and extremely accommodating, and I'm hoping they make a very solid database. The featureset looks great, and the admin interface is fantastic. I would definitely recommend giving it a try.
- m0th87 14y ago
  Could you expand on the buginess? Was it aesthetic issues, or did you ever face problems like data corruption?
  - jdoliner 14y ago
    RethinkDB is still very young software and will take some time to mature. The worst issues that we had during the last release cycle did result in data corruption, one due to a bug in our code. Another due to a filesystem we weren't expecting (which we still consider to be a bug in our code.) Right now we can't recommend RethinkDB for production ready code but we're working very hard to get it to that point. Part of this is beefing up our internal testing system which we've made a big push on during the last release cycle. Part of that is fixing all of the bugs that users submit until they stop finding serious ones.
    - StavrosK 14y ago
      What jdoliner said. A few were cosmetic, but I think I experienced some data corruption as well (it was a test dataset). The team was extremely responsive and fixed the bugs in a few hours, and RethinkDB is clearly marked on their website as still an alpha, so I can't blame them. I'm sure it will be a fantastic product when it matures, and I can't wait for a stable release so I can try it out.
    - jbellis 14y ago
      Maybe I'm just an old fart, but I think it's less misleading to label "not production ready" releases with a 0.x.
      - coffeemug 14y ago
        Oh, that's very true. We used an internal versioning scheme and it became exceedingly difficult to change all the repo tags, internal references, etc. so we decided to just bite the bullet and use the same scheme publicly and privately. I wouldn't have done this if we could go back in time, but you know what they say about hindsight :)

bjourne 14y ago

It's great to see all these new ideas in the db arena. But one thing I don't understand at all is why they diss the idea of having data integrity. Am I the only developer who actually likes working with relational data and do not think of a schema as a straight-jacket? Am I the only one getting burnt by MySQL and SQLite playing loose with types and silently coercing data almost randomly? Check constraints are also great and has saved my ass so many times. It's so much easier to debug a problem when the crash occurs when you are inserting the data than in a wrong calculation much further down the line. Postgres for example, allows you to create regular expression constraints which you could use to ensure that a text column only contains a valid variable name. Exclusion constraints are even better, if you have a table with allocations (date ranges, integer ranges, etc) you can check so that none of the allocations overlap. Plus about a million other ways you can constrain your data. That's the killer features for me. They have helped me debug problems so many times that I consider them almost essential to writing good web applications. So why does almost all new database projects seem to neglect them?

m0th87 14y ago
Schemas have saved my ass a million times too, but schema migrations are a pain. I'd love a database that's loose with types by default, but allows you to add declarative specifications for types. Documents are checked at insert/update time, but otherwise the specifications play no role in how the data is stored. That way you get schemas, but only when you need them. And migrations don't require heavy collection-wide locking; instead, you just change the constraints you enforce and lazily update old documents. Postgres does to an extent with CHECK constraints, but you still have to do an ALTER TABLE if you change the underlying type of a column.
- petergeoghegan 14y ago
  Yes, you still have to do an ALTER TABLE to change the type of a column within Postgres, because, well, that's just how it's done. This does not necessarily mean that the table will be rewritten, which I assume is what you're concerned about. See this item from the Postgres 9.2 release notes: Reduce need to rebuild tables and indexes for certain ALTER TABLE ... ALTER COLUMN TYPE operations (Noah Misch) Increasing the length limit for a varchar or varbit column, or removing the limit altogether, no longer requires a table rewrite. Similarly, increasing the allowable precision of a numeric column, or changing a column from constrained numeric to unconstrained numeric, no longer requires a table rewrite. Table rewrites are also avoided in similar cases involving the interval, timestamp, and timestamptz types.

ksev 14y ago

Does this include the new wire format? That was talked about here: http://www.rethinkdb.com/blog/rethinkdb-wire-protocol-call-for-comments/ http://www.rethinkdb.com/blog/rethinkdb-wire-protocol-call-f... I'm itching to write a toy client in clojure.

coffeemug 14y ago
No, this doesn't include the wire protocol updates yet. That's slated for 1.4 -- sorry!
- ksev 14y ago
  Alright, gives me more time to nail down a nice query DSL :) Nice to see OSX support, simplifies development quite a bit for us mac users.

SnowLprd 14y ago

I commend the RethinkDB folks for supporting Mac OS X explicitly. However, the .pkg installer, while handy for folks that prefer that installation method, installs to /usr/bin/ and /usr/share/ -- areas that are traditionally reserved for system tools provided by Apple. Sure, the DMG also contains an uninstall-rethinkdb.sh script, but I'm still left quite unwilling to kick the RethinkDB tires on my primary Mac workstation. A better method, in my opinion, would be for the RethinkDB devs to contribute a Homebrew formula. That way everything would be installed into /usr/local/ by default, and updates would be a quick "brew upgrade rethinkdb" away. Am I the only one who would prefer that? UPDATE: It seems they had originally planned on a Homebrew formula but thought the .pkg format was better. Clearly, I disagree with that. Want to offer both? Awesome. But if you're going to pick one or the other, I think Homebrew is the vastly superior method. More here: https://github.com/rethinkdb/rethinkdb/issues/5 https://github.com/rethinkdb/rethinkdb/issues/5

coffeemug 14y ago
The reason we did that is because /usr/local/bin isn't on the default path on many OS X systems, and we didn't want the installer to modify the user's PATH. The thing about Homebrew is that it's great once you have it, but the user experience of actually installing it can be quite a pain, and we didn't want users who don't have it to have to go through the trouble. That being said, I still think it would be great to contribute a Homebrew formula.
- SnowLprd 14y ago
  Regarding the first point, which OS X systems are you referring to? The default PATH on Mountain Lion definitely contains /usr/local/bin, as you can see here: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin With respect, I don't share the view that installing Homebrew is a pain. Even the most inexperienced would-be developer can follow the very simple guide I (very coincidentally) posted yesterday: http://hackercodex.com/guide/mac-osx-mountain-lion-10.8-configuration/ http://hackercodex.com/guide/mac-osx-mountain-lion-10.8-conf... But it seems you guys are amenable to offering both the .pkg installer and a Homebrew formula, which would be great. :^)

themgt 14y ago

http://rethinkdb.a.pogoapp.com/ http://rethinkdb.a.pogoapp.com/ - our demo has been updated to 1.3.1

DeepDuh 14y ago

I can't find information on how (or whether) you handle users. Is there some built-in per-document read/write lock based on user access for example? This is the most important feature I miss in CouchDB.

coffeemug 14y ago
Do you mean permissions (i.e. granting access to tables based on authentication)? If so, Rethink doesn't have that yet, but it's definitely on the list.

gummydude 14y ago

can't wait for final golang driver, kudos for listening.

coffeemug 14y ago
You might want to check out community one for now -- https://github.com/christopherhesse/rethinkgo https://github.com/christopherhesse/rethinkgo (perhaps even contribute -- hint hint)
- cshesse 14y ago
  This driver attempts to match the official drivers as closely as is reasonable. It has almost all of the functionality of the official drivers now, but won't have a stable-ish API or actual tests until the end of December. Let me know if you have any feedback, this is the first Go language library that I have built.