
RethinkDB example apps - coffeemug
http://www.rethinkdb.com/blog/rethinkdb-example-apps/
======
mercurial
Thanks for taking the time to do this. I have only looked at the Python
example, but I think it highlights a basic issue with the API:

    
    
        r.table('todos').get(todo_id).run(g.rdb_conn)
    

It would be more natural to have it go the other way:

    
    
        g.rdb_conn.run(r.table('todos').get(todo_id))
    

This way, the connection runs the request instead of the other way round.

Also, you are opening and closing DB connections with each HTTP request. I
imagine this is for the purpose of simplifying the example. However, it does
make me curious: how expensive is the creation of a new connection? Are
connections thread-safe? Would it make sense to have connection pooling?

~~~
wmrowan
This is Bill @rethinkdb

The distinction between query.run(conn) and conn.run(query) is very fine
indeed. There has been much discussion about this and there are both solutions
have their merits. At one point we even supported both but decided the
simplicity of having only one solution merited dropping the other.

Creating a new connection involves opening a TCP connection and sending a
message to validate the driver to the server, altogether a few round trips.
There is a small bit of per connection state stored on the server but since
RethinkDB uses a custom coroutine implementation for concurrency support this
does not amount to the overhead of an independent OS thread for each
connection.

Invoking the query with a specific connection object is thread safe. There is
a feature designed to help REPL users that stores the last connection in
global state that is slated for removal in the upcoming release (1.4) that is
obviously not re-entrant.

It would make sense to have connection pooling, especially in the python
driver where connections block on requests. This is an idea we're exploring
but is lower down on the priority list. As it is a fully client side feature
there is nothing stopping 3rd party driver developers from implementing a
solution though the official drivers will have to wait for other priorities.

~~~
mercurial
Thanks for the detailed answer. I completely agree wrt having only one
solution. Looking forward to trying it out :)

------
dkhenry
I would love to try out your DB, but your build system is garbage, and I mean
that in the most constructive way possible. I know you guys put lots of effort
into it, I can tell as I am reading through it trying to get it to compile on
my Fedora system. Please for all that is good in this world take the time
_now_ and switch to a sane build system. I know its cool that you scripted
everything in Make, but this is stupid how hard it is to build on Fedora.

I am putting together a patch and instructions for fedora, but this is silly.

EDIT: <https://gist.github.com/4696023> Turned out to not be too big of a
change BTW.

~~~
coffeemug
_I would love to try out your DB, but your build system is garbage_

If you only knew how much we agree with you :) We have an engineer working on
that now, so it will soon be much, much nicer. Also, thanks for the
instructions, I'll post them on the build page after I confirm everything.

~~~
gnud
I'm the maintainer of the archlinux AUR pkgbuild - a better build system would
be much appreciated :) For now, I do 3-4 sed invocations over your various
Makefiles.

If you want to have a look at what we need to hack our way around, take a look
at <https://aur.archlinux.org/packages/re/rethinkdb/PKGBUILD>

~~~
coffeemug
Thanks -- I've opened an issue for the new build system
<https://github.com/rethinkdb/rethinkdb/issues/286> and posted this info.
We'll try to take it into account as we develop the new one. Please comment if
you have feedback/ideas!

------
nlh
I continue to be very psyched about RethinkDB - looks like an awesome product
coming together nicely.

As a boring non-cutting-edge, non-expert Rails person, any word on projects a
la Mongoid to give a nice ActiveRecord-style ODM to guys like us? Would LOVE
to be able to play with Rethink in place of Mongo.

(Also, as an aside, if I were about 3 years more advanced in my ruby skills
I'd totally volunteer to start that project. But I'm not. So I can't ;)

Keep up the good work guys.

~~~
coffeemug
There is a Python ORM already (<https://github.com/nviennot/nobrainer>) but no
Ruby one yet. I suspect it would be pretty easy to port Mongoid to rethink, so
I wouldn't be surprised if a port pops up soon.

Thanks for your interest -- we'd really love to get everything out ASAP, but
the team has limited resources and we have some more low-hanging fruit to take
care of first.

~~~
daemon13
The link above is to Ruby ORM "nobrainer", may be edit your comment to
clarify.

No Python ORM :-(

------
a9entroy
Could you make a RethionkDB Heroku Add-On ? I would definitely try it out
then.

~~~
coffeemug
Noted -- we'll try to get that up soon.

~~~
dotmanish
Heroku Add-Ons are essentially hosted services, just with an automated billing
tie-up with Heroku.

What the other comment-er is asking for is a hosted instance.

------
omervk
I really like RethinkDB, but the lack of a driver for JVM languages (Java,
Scala, etc.) is a showstopper for me. I read that you're revamping your driver
architecture and am anxiously looking forward to a JVM driver (more than
willing to write a Scala-friendly wrapper - let me know if you're interested).

~~~
coffeemug
Thanks -- helping with a Scala wrapper would be great. Only a few weeks left
until the new API is out. I wish we got it right on the first release, but
hey, better late than never (there was _a lot_ we learned from the first
version).

~~~
omervk
Let me know via twitter: @omervk

------
ovi256
For those interested, there's an Easter egg in the lower right corner, it's
that very small lambda icon linking to this Youtube vid:

<http://www.youtube.com/watch?v=2ZUNLV7e3vU>

"Star Trek - Data asks his creator a question"

------
taf2
this looks great! thank you so much. This gives me what i needed to finally
give rethinkdb a try.

------
mylittlepony
Why not PHP? =/

~~~
coffeemug
It will take a bit of time to get a PHP driver going. Hang on!

~~~
dkhenry
While I don't know what they have planned. Might I say part of the issue might
be PHP's _extremely_ poor protobuf support.

~~~
coffeemug
There are a few ways to deal with this issue -- contribute to the PHP protobuf
library, or have an alternative layer on the server that accepts a more
portable but less efficient serialization format. It's a little frustrating,
but wouldn't be _too_ difficult to solve.

