Why not PHP? =/
RethinkDB example apps
11–20 of 35 posts
Re: RethinkDB example apps
#12Re: RethinkDB example apps
#13Thanks 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)
g.rdb_conn.run(r.table('todos').get(todo_id))
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?
Re: RethinkDB example apps
#14Thanks 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 r…
I actually prefer the first of those - I find it easy to read than the second one - probably because the calls are chained rather than being nested.
Re: RethinkDB example apps
#15Thanks 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 r…
This way, the connection runs the request instead of the other way round.
I don't know if I'd call it an issue with the API -- there is a pretty active debate going on about it: https://github.com/rethinkdb/rethinkdb/issues/256 Please chime in there with your POV, it would really help!
how expensive is the creation of a new connection?
Connections aren't thread safe on the clients. It's very efficient to open a connection to the server, but it still requires a TCP handshake. This is a good low-level API -- we'll build a connection pool on top of that soon (I just opened an issue for it here -- https://github.com/rethinkdb/rethinkdb/issues/281). People seem to want one because they're used to one, but it hasn't really been necessary in our testing.
Re: RethinkDB example apps
#16Why not PHP? =/
It will take a bit of time to get a PHP driver going. Hang on!
Re: RethinkDB example apps
#17Could you make a RethionkDB Heroku Add-On ? I would definitely try it out then.
Noted -- we'll try to get that up soon.
Re: RethinkDB example apps
#18Thanks 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 r…
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.
Re: RethinkDB example apps
#19Thanks 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 r…
I actually prefer the first of those - I find it easy to read than the second one - probably because the calls are chained rather than being nested.
Alternatively, you could do this:
g.rdb_conn.table('todos').get(todo_id).run()
Re: RethinkDB example apps
#20I 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.