I love the elegance of ReQL and how well it works in dynamic languages, but I still can't figure out a good way to port that lambda syntax used in python into the Java driver.
RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
31–40 of 79 posts
Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
#32Still no official Java driver? How unfortunate...
I know its not an official driver, but I maintain the Community Java driver here[1]. If its missing something you would need feel free to open an issue and I can add it for you. I have been using RethinkDB with java for a few projects and it works well enough for me.
Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
#33RethinkDB is my favorite piece of my current tech stack. I tell everybody I know about it, and I'm soon to release some blog posts and speak at a Meetup showing off what it is good at and how to get started - I really just can't say enough good stuff about these guys. A high level overview from someone who has used it in production since 1.10 (about six months): Pros: * ReQL is a beautiful DSL that makes querying and…
Thanks for the great feedback! If you're speaking at a meetup, let me know (mike@rethinkdb.com) -- we'd be happy to send over T-shirts (and stickers, etc.), as well as spread the word about the event.
Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
#34I love the elegance of ReQL and how well it works in dynamic languages, but I still can't figure out a good way to port that lambda syntax used in python into the Java driver.
What about lambda expressions in Java 8? I haven't programmed in Java in years, so unless there are limitations I'm not aware of, they seem like a great fit.
Without those, doing an elegant driver would be pretty hard, which unfortunately probably means we'll never get good ReQL support into legacy Java.
Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
#35This is great. I love RethinkDB and had a lot of fun writing Erlang and Elixir drivers for it.
Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
#36I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface. I get it - they are marketing themselves as NoSQL but they are infact providing almost exactly the same set of features that say MySQL provided back in the day a simple "fast" sub-set of SQL. Instead they use the lack of an interface as a marketing gimmick... when in reality we have to learn a new query language... :(
One reason is that SQL only lets you work with flat relational tables. MongoDB and RethinkDB let you store complex JSON-like objects as values, and extending SQL to query and manipulate those kinds of structures is hard. The closest attempt I've seen is Google's BigQuery. Another reason is that SQL does its best to decouple the query (what you're asking for) from the execution plan (how it actually gets evaluated). B…
I have no experience with RethinkDB, so maybe they did it right, but I have quite a bit with Mongo.
MongoDB's querying is nowhere near as powerful as SQL. And understanding its limitations and pain points are essential when structuring your data. Otherwise you'll never really scale unless you've got data that's embarrassingly easy to query (eg: filtering on 1 or 2 indexed fields).
Being able to write JS map-reduce queries is fine when you need to do stuff ad-hoc, but none of it can be used in production at scale. Then there's the aggregate framework which helps quite a bit but still doesn't offer the same level of performance I'd expect from Postgres, MSSQL, or Oracle. Things get really yucky when you have to start unpacking arrays - especially since there's a memory limit on $sort and $group. There are further issues related to skipping being slow on large collections because it must step through.
And to cope with these limitations you need to invest a ton of time into coding around them. The freedom of the database being schemaless? Gone. You must carefully structure data and decide up-front how it needs to be queried - or cope with poor performance.
And those complex queries, when written in ugly JSON, aren't the most human-readable things in the world. Certainly not any better than SQL.
I'd rather just invest the time in learning SQL than partake in the mental gymnastics necessary squeeze high-performance non-trivial queries out of MongoDB.
I understand MongoDB is a big hit with people who use it for low volume internal tools or people building MVPs. I can totally understand how its an awesome tool for those. But rusty old SQL starts looking better when your app scales and the business demands change.
Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
#37Earlier quoted context omitted.
So, to be clear here, you have created two fundamental things (both called "filter") -- A pre-group and a post-group filter. Users must still understand the difference and when to utilize them. SQL just happens to call those WHERE and HAVING instead of "filter" both times.
You're right, but it's not just `filter`. Any command that can run on a group can run on a full table and vice versa. For example: # get a sample of 3 elements from a table r.table('foo').sample(3) # get a sample of 3 elements from each group r.table('foo').group('category').sample(3) You could say that we created two versions of `filter`, and `sample`, and every other command. But another way to say it is that we us…
Yeah, it's definitely more expressive and terse I just don't think your argument against WHERE/HAVING is incredibly strong. Someone could also just do subqueries and only use WHERE and achieve the exact same behavior that you offer (albeit with a ton more typing).
HAVING exists because it was created prior to subqueries/dynamic tables, otherwise we'd have been likely to just use:
select * from (select category, sum(num_comments) as comments from posts group by category) as temp where comments > 7Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
#38[deleted]
Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
#39I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface. I get it - they are marketing themselves as NoSQL but they are infact providing almost exactly the same set of features that say MySQL provided back in the day a simple "fast" sub-set of SQL. Instead they use the lack of an interface as a marketing gimmick... when in reality we have to learn a new query language... :(
> I don't understand why databases like RethinkDB and MongoDB don't just provide a SQL interface. Actually, it's a really good question. I'm one of the ReQL designers at Rethink, and I was the one pushing for no SQL compatibility. Here is some of my reasoning (we could talk about this for days, though): * Even SQL designers would tell you SQL isn't a very good programming language. It even looks like Cobol! Imagine i…
Good arguments, though only the last one seems like a true objection.
I think, If I were implementing a database from the ground up, I'd indeed make my own query language--SQL does suck--but I would probably strive to accept SQL as an option, with the proviso that it's "just SQL syntax with ThisDB's semantics."
This would let people point their old applications, written under "the database is just an SQL-speaking dumb store for simple CRUD operations" assumptions (e.g. any ActiveRecord app), at the new DB and get somewhat-sensible results out, while still letting them write new applications against the new API.
The alternative is forcing any user with existing services to hack up some sort of application-level back-and-forth replication between their old DB and your new DB during the long-and-possibly-indefinite migration period, rather than just migrating in one fell swoop.
Re: RethinkDB 1.12: simplified map/reduce, ARM port, new caching infrastructure
#40> you no longer have to manually specify cache sizes for tables to prevent running over memory and into swap
I'm really glad you're addressing this. Does this auto-sizing apply to RethinkDB's memory usage in general? The last time I tried using it on a small VPS, I set my table's cache size really low, but I still ran out of memory whenever I ran queries on a large table.
Definitely looking forward to secondary index export/migration and to upgrades without the export-import cycle.