

RethinkDB 1.3 is out, now available on OS X - coffeemug
http://www.rethinkdb.com/blog/rethinkdb-13-release/

======
bjourne
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
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.

~~~
lwat
> ...you still have to do an ALTER TABLE if you change the underlying type of
> a column.

I don't see why this is a problem? How often do you update really big
(hundreds of millions of rows) columns' data types in practice? Most of the
time you'd change type early in development when you don't have that much data
in the table yet which makes it pretty much instantaneous. If you really need
to update the data type for a supersized table you could always make a new
column instead and migrate lazily to that in the background. But all of this
happens so rarely that in my view it's a silly excuse to dump all the great
benefits you get from having an enforced database schema.

~~~
saurik
> If you really need to update the data type for a supersized table you could
> always make a new column instead and migrate lazily to that in the
> background.

I do this "irritatingly often". That said, the fact that while I'm doing it I
have the advantages of schemes to make certain I do it _correctly_ is
_amazing_ ;P. Even in a world where I have to do this every day, I still
wouldn't feel "ok, let's not have a schema at all" would be a better fix to
that problem.

(To be clear: I am not "disagreeing" with you: I am agreeing with a point that
is even stronger than the one you made, as I think you ceded too much ground
;P.)

------
SnowLprd
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>

~~~
coffeemug
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.

~~~
patrickg
When installing via .pkg, you can place a file in /etc/paths.d that adds to
the path. For example, when you install in /usr/local/rethink/, you just add a
file (e.g. /etc/paths.d/rethink) with one line: /usr/local/rethink/bin. Thats
it, very easy.

~~~
coffeemug
Ah cool, thanks. Will do.

~~~
sandstrom
Would you like to leave a comment here if you update the package to install
into /usr/local, I'd also prefer to use that directory.

Congrats on the new release! You are definitely doing a great job making
developers love RethinkDB, feels like you already generated loads of interest.

~~~
coffeemug
I added an issue for this --
<https://github.com/rethinkdb/rethinkdb/issues/171>

I'll try to comment here as well when this is done!

------
MatthewPhillips
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.

------
ksev
Does this include the new wire format? That was talked about here:
[http://www.rethinkdb.com/blog/rethinkdb-wire-protocol-
call-f...](http://www.rethinkdb.com/blog/rethinkdb-wire-protocol-call-for-
comments/)

I'm itching to write a toy client in clojure.

~~~
coffeemug
No, this doesn't include the wire protocol updates yet. That's slated for 1.4
-- sorry!

~~~
ksev
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.

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

~~~
StavrosK
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
Could you expand on the buginess? Was it aesthetic issues, or did you ever
face problems like data corruption?

~~~
jdoliner
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.

~~~
jbellis
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
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 :)

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

------
DeepDuh
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
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
can't wait for final golang driver, kudos for listening.

~~~
coffeemug
You might want to check out community one for now --
<https://github.com/christopherhesse/rethinkgo> (perhaps even contribute --
hint hint)

~~~
cshesse
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.

