Hacker News Reader

Comment by StavrosK | Hacker News Reader

I've tried RethinkDB (back when it wouldn't balance shards correctly!), and I liked it a lot. Especially the automatic sharding is magical, I will definitely try it out again when it's stable.

That said, it is also my opinion that the ORM syntax needs a bit of love, for all the reasons stated above. Especially .run() feels a bit weird, can you make queries lazy (like Django's QuerySets, which only run when evaluated)?

P.S. If the rest of the RethinkDB team are as good at DOTA 2 as Marc is, I want to play with you too!

View on HN

> Especially .run() feels a bit weird, can you make queries lazy (like Django's QuerySets, which only run when evaluated)?

In a way queries are lazy. You can write a query and without calling `run` on it nothing happens. The whole chained ops are executed at once when `run` is called.

> That said, it is also my opinion that the ORM syntax needs a bit of love, for all the reasons stated above.

This is not an "ORM" per se. It's a query API or data manipulation language. The next version will bring a few improvements to it.

> In a way queries are lazy. You can write a query and without calling `run` on it nothing happens.

That's not lazy, though, that's just doing nothing :P Lazy would be not running anything until you evaluated the last link in the chain, so, in Django:

    model = User.objects
    model = model.filter(name="Alex")
    model = model.filter(hero="Dazzle")
    model = model.filter(abandons<2)
    list(model)

and the query would only be executed when wanting to turn the QuerySet into a list.

I think your examples would also be a bit clearer if you forewent the r.db("test") step and just did:

    db = r.db("test")
    db.query("foo").bar().run()

which is more explicit.

Probably this is only "semantics", but I find these two quite similar :). I like the idea of having the query being executed only when needed, but I'm not sure that's always possible (or optimal with large result sets).

thanks,

alex @ rethinkdb

Laziness typically implies something isn't evaluated until you need the data (e.g. you coerce it to a native language data structure, or you need to print it, or write it to a file or network). So saying list(query) lazily evaluates the query, while saying query.run() is a more strict (explicit) evaluation model.

I actually think strict is better here, but that's a different discussion altogether :)

Sure, they are almost identical, but one doesn't need .run() :)

I don't see how it wouldn't be optimal, since lazy evaluation is a superset of eager evaluation (you can invoke it whenever you want).

Both solutions are lazy. While ReQL requires .run(), the Django ORM requires you to do 'list()' (or probably other form of iterator over it). I'd say the only difference is that one is explicit and the other one is implicit.

.run() is also bad. What connection is it being run on? The most recently opened connection? In a global variable somewhere? For anything larger than a short script, you should use query.run(conn), or conn.run(query).

Yes, especially in web applications. Found that out the hard way.

Reply on news.ycombinator.com