
Try RethinkDB in your browser - coffeemug
http://www.rethinkdb.com/tutorial/
======
randomdrake
Alright, I tried it. Frankly, I'm confused as to why this is getting so many
up-votes. If someone could elaborate what they enjoyed so much, I'd be
interested to hear.

I didn't enjoy this experience one bit. It didn't feel interactive to me. Each
step is basically "Run this query that is already typed out for you" without
any explanation, whatsoever, about what each part of what I was writing was
doing. This was followed by an invitation to click a link to documentation to
try something else on the line of code you don't understand.

It begins with:

>r.db('test').tableCreate('tv_shows').run()

My first questions: what is r? What does db() do? Is there a test database
somewhere? Why do I have to call run() when there's a button saying "Run this
query"? Do you sometimes not run() things?

The tutorial doesn't remember your position if you go back to it so it's a
good thing, I guess, that it opens a new tab for you when you access the
documentation to list the tables.

Let's move to the second step:

>r.table('tv_shows').insert([{ name: 'Star Trek TNG', episodes: 178 }, { name:
'Battlestar Galactica', episodes: 75 }]).run()

Even more questions: What happened to r.db('test') that I needed to use? Is r
now that database? Why didn't I just do r.tableCreate('tv_shows') before?

I did this with basically every step of the process but stopped just short of
finishing because I wasn't learning much and wasn't sure where it was going. I
found myself simply wondering what the heck RethinkDB was.

This tutorial could really use some more explanation, interaction, flow and
direction. Tell me what I'm about to do. Tell me why what I'm about to do is
worth my time and cool. Start with r, go from there. At least I won't be lost
from the get-go.

Let me write stuff out as you're telling me what I'm doing. That's
interacting.

~~~
coffeemug
This feedback is wonderful, thank you. It's often hard to do a good job when
you're neck deep in your own concepts because you lose perspective. (I'm
responsible for the tutorial, btw, and it's my screwup). I'll make everything
work better.

To answer your questions here:

> what is r?

It's a module where all the RethinkDB operations are defined. The tutorial is
running the same JavaScript driver code as you'd run if you connected to C++
RethinkDB server from node.js, which is why you have to start with `r`.

> What does db() do?

It refers to a database named 'test'. This is where you're creating the table

> Is there a test database somewhere?

Yes. It's set up by default at the beginning.

> Why do I have to call run() when there's a button saying "Run this query" do
> you sometimes not run() things?

Because you can type multiple queries in the text box. Every time you end a
query with `.run()`, that's when it goes to the server and gets executed
there. We've been talking about not having people type `.run` for a single
query, but it's a bit difficult to solve.

> What happened to r.db('test') that I needed to use? Is r now that database?

If you omit r.db() at the beginning of the query, it picks a default one
(which is 'test'). It's the same as you'd do in MySQL.

> Why didn't I just do r.tableCreate('tv_shows') before?

We thought allowing tableCreate in a default database allows people to make
mistakes too easily, so we disallowed it. It confuses people, so we'll add it
back. Sorry for confusion.

~~~
JPKab
Just a note for everyone on HN who is starting a business or working on any
project: THIS IS HOW YOU SHOULD RESPOND TO CRITICISM! Classy, doesn't expect
the user to research beyond the page, etc.

I have to confess: my initial reaction was "isn't this kind of self-
explanatory" and "dude, if you want to know what rethinkdb is, look at their
damned website" or even the dreaded, and admittedly elitist "if you have to
ask, its not targeted at you." However, reading your response, I am reminded
that I can be a smug asshole, and I'm going to remember how you responded for
the day I release something to the public.

Your response, on top of the fact that I've already examined, installed, and
liked your product, adds even more to my confidence that you guys are creating
a great longer term product.

~~~
coffeemug
I once read a quote by Bertrand Russell that really helped me respond to
people better. He was talking about studying philosophy, but it applies to
understanding points of view in general. Here it is:

 _In studying a philosopher, the right attitude is neither reverence nor
contempt, but first a kind of hypothetical sympathy, until it is possible to
know what it feels like to believe in his theories, and only then a revival of
the critical attitude, which should resemble, as far as possible, the state of
mind of a person abandoning opinions which he hitherto held. Contempt
interferes with the first part of this process, and reverence with the
second._

This helped me a lot, hope it helps you too!

------
ebbv
I don't understand how this is giving any advantages over the standard object
interface.

How is:

> r.table('tv_shows').insert([{ name: 'Star Trek TNG', episodes: 178 }, {
> name: 'Battlestar Galactica', episodes: 75 }]).run()

Easier than:

> db['tv_shows'].push([{ name: 'Star Trek TNG', episodes: 178 }, { name:
> 'Battlestar Galactica', episodes: 75 }]);

Seems to me like a totally unnecessary abstraction which only adds
complication and potential points of failure and bugs.

EDIT:

Ok never mind this does actually create a real database. From the demo it
seemed like it was just creating a JSON object.

~~~
coffeemug
In the former case you're creating a query (similar to SQL insert) that puts
data into the database. You can then take advantage of indexing, sharding,
durability guarantees, caching, a specialized query language, and all the
other benefits of a database system.

In the latter case you're creating a data structure in the host language
(which of course is immensely useful, but completely different).

~~~
ebbv
My mistake, from the demo I thought this was just creating a JSON object, and
there was no actual backend database.

~~~
coffeemug
Right. The demo implements the backend database in Javascript, so you can run
real queries against it. (Still, the whole thing is confusing and I'll make it
much, much better)

slava @ rethink -- I was responsible for the tutorial

------
wildchild
One thing I can't understand is if "RethinkDB is built to store JSON
documents", why then there are tables?

And also, probably I should better explore website, but is it transactional?
In other words, is it possible to save multiple documents and RethinkDB server
will reject them in case of conflict, just like all-or-nothing semantic in
couchdb before ver. 0.9?

~~~
coffeemug
_if "RethinkDB is built to store JSON documents", why then there are tables?_

JSON docs are stored in tables -- a table is just a collection of JSON
documents. We of course also support arrays, but the reason why we start with
tables as a primitive is that it allows doing significant optimizations that
otherwise would be very hard/impossible. If the entire DB was one huge JSON
document, optimizations would be much more difficult to do. Grouping docs into
tables essentially gives the system a hint as to the usage intent.

 _is it transactional?_

Only for changes on a single document. There are no transactional guarantees
on queries that touch more than one document.

~~~
wildchild
> There are no transactional guarantees on queries that touch more than one
> document.

Any plans to change it in future?

~~~
coffeemug
May be. It's a bit far off (there is more low-hanging fruit), but I'd never
say never.

------
ScottBurson
It doesn't look like this site was built with Weblocks :-)

------
throwawayG9
Still no PHP support?

~~~
wmrowan
Currently RethinkDB has official drivers for three languages, Python,
JavaScript, and Ruby. I hope you understand why it would be difficult for us
to support many more than this. Eventually we're counting on support for 3rd
party drivers from the community. In fact, there are already a few early
community drivers from some intrepid contributors including for Haskell and
Go.

We've had lots of requests for more drivers and lots of offers to build them,
but we've asked our volunteers to hold off while we revamp the driver
interface to make it significantly easier to build drivers for RethinkDB.
Having written the first JS driver myself and the new version I can attest to
the much greater ease of doing so with the new API.

The next release (1.4) due very soon will include these changes and a driver
development kit to support 3rd party efforts. After that I'm sure you'll see a
PHP driver emerge very quickly.

------
tucson
should one use this instead of MySQL, and why? I couldn't find this question
in the FAQ.

~~~
jabagonuts
They have a page comparing themselves to MongoDB
<http://www.rethinkdb.com/docs/comparisons/mongodb/>

~~~
coffeemug
There is also the biased comparison: <http://www.rethinkdb.com/blog/mongodb-
biased-comparison/>

------
neumino
I'm a ReQL guru!

