Why is it so trendy these days to say that everything was built "with love"?
Would you much rather it was not built with love?
I really fail to see how saying "built with love" matters at all.
We use RethinkDB
11–20 of 78 posts
Re: We use RethinkDB
#12I've always wondered what's the best way to integrate a database engine with the application. 1) Use a middleware/ORM/Whatever which abstracts away the query-lang of the db, and provides a pluggable multi-db support 2) Just use native db query language with all exclusive features of the engine. Companies like workshape.io, why do they prefer the latter?
Abstractions are leaky. [1]
ORM systems are highly complicated abstractions.
Most of your developers will use them without understanding how they work. In many cases, the only way to understand how they work is to read the source code.
They have magic features that are advertised as convenient but when they inevitably do something you don't want them to do you'll tear your hair out trying to circumvent them.
They put lots of complicated weird stuff in your stack traces so when something goes wrong with "the database stuff," which is probably going to happen every day, you will feel confused and overwhelmed.
ORM was famously referred to as "the Vietnam war of computer science" by Ted Neward. [2]
There's a point that I think is even more important than the unruly and bewildering complexity of ORM, but I'm not sure I know how to formulate this point.
One way to formulate it would be to point out that your dichotomy of two choices is missing an alternative, so I present:
3) Code your data access in a separate module exposing query & save functions that make sense within your domain model.
In a reasonably complex system, this module might consist of fifty functions that concatenate SQL strings or whatever. In most cases, I'd bet money that rewriting this module to support some other data storage—especially if there are integration tests—would be easier and more pleasant than switching your ORM and then dealing with the random problems that will inevitably occur.
And when some query fails or is slow, the developer issued to fix it will just go into the file, find the query, and change it. It's simpler, there's less obscure technology to worry about, fewer things to get angry at.
[1]: http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
[2]: http://blog.codinghorror.com/object-relational-mapping-is-th...
Re: We use RethinkDB
#13+1 to using RethinkDB! I'm also using RethinkDB in production, and I love it! The only issue is that you have to set up persistent filters via iptables in addition to having an authKey. They do have a guide[0] for that, however they do not provide any instructions for ensuring that the filters on iptables stay up, or how to restore them if they are temporarily wiped out :/ [0] http://rethinkdb.com/docs/security/
It's a good point. Though I think people tend to run these on non-public machines. Even most of AWS is on VPC nowadays.
Re: We use RethinkDB
#14From RethinkDB docks [1], I am still a bit confused how this locking system works for read/write and also a bit skeptical regarding their claim that 'in most cases writes can be performed essentially lock-free'. I am using MongoDB and didn't have many issues when my databases had 120,000 documents either, the problem began when we hit the millions... The combination of write locks and our need for dynamic queries (me…
FYI, with MongoDB, just because you can't and shouldn't index everything, doesn't mean you can't have any indexes... if your most common fields bring your queries down, they're still pretty helpful.
I actually really like where RethinkDB is headed, and within the year most of my issues should be resolved.
Another couple databases to consider, depending on your needs would be ElasticSearch and Cassandra... it reallly depends on your use case.
Re: We use RethinkDB
#15We use RethinkDB in production and our main frustration lies around the lack of automatic failover. We're looking forward to 2.0, which is supposed to bring automatic failover (using Raft for consensus) to RethinkDB.
That was one of my two bigger issues earlier on... the other one being geographic based searches (which is now implemented iirc).
Re: We use RethinkDB
#16We use RethinkDB in production and our main frustration lies around the lack of automatic failover. We're looking forward to 2.0, which is supposed to bring automatic failover (using Raft for consensus) to RethinkDB.
Slava @ RethinkDB here.
Unfortunately automatic failover won't be a part of 2.0, but it will happen very quickly after that. Please hang in there, we expect to ship this feature some time in May.
I just saw a demo of the failover feature yesterday from Tim Maxwell (the lead engineer on this), and it's really impressive! Another side benefit of this feature is live reshards -- you'll be able to reshard/rebalance data without any availability loss on the cluster.
The code is there and just needs a bit more polish and a lot of testing. I'm very excited to get this out, it's probably the last part of RethinkDB that I'm not 100% proud of yet (but will be in a month or two).
Re: We use RethinkDB
#17Why is it so trendy these days to say that everything was built "with love"?
That's a good point! Though in RethinkDB's case I'd like to make an exception.
~30,000 commits and long discussion such as this one: https://github.com/rethinkdb/rethinkdb/issues/281
Re: We use RethinkDB
#18We use RethinkDB in production and our main frustration lies around the lack of automatic failover. We're looking forward to 2.0, which is supposed to bring automatic failover (using Raft for consensus) to RethinkDB.
That was one of my two bigger issues earlier on... the other one being geographic based searches (which is now implemented iirc).
Yep, geospatial support has been in since 1.15.
Re: We use RethinkDB
#19I've always wondered what's the best way to integrate a database engine with the application. 1) Use a middleware/ORM/Whatever which abstracts away the query-lang of the db, and provides a pluggable multi-db support 2) Just use native db query language with all exclusive features of the engine. Companies like workshape.io, why do they prefer the latter?
Abstractions are leaky. [1] ORM systems are highly complicated abstractions. Most of your developers will use them without understanding how they work. In many cases, the only way to understand how they work is to read the source code. They have magic features that are advertised as convenient but when they inevitably do something you don't want them to do you'll tear your hair out trying to circumvent them. They put…
Alternatively.. wrap each domain's data as a separate micro-service, with a convenient API... Though it really depends on how you can break down the boundaries of your application's data. Then you can persist/represent that data however you like.
Re: We use RethinkDB
#20I've always wondered what's the best way to integrate a database engine with the application. 1) Use a middleware/ORM/Whatever which abstracts away the query-lang of the db, and provides a pluggable multi-db support 2) Just use native db query language with all exclusive features of the engine. Companies like workshape.io, why do they prefer the latter?
Well, here's where the difference between query builders and ORMs comes in.
Query builders (usually integrated with ORMs) are usually used by people who don't want to write any SQL. SQL is very performant and powerful, but not that easy to understand or write. This is especially so when you think about the context switch between programming languages and SQL.
The advantage of some of the NoSQL databases (MongoDB and RethinkDB, for example) is that you have the luxury of using an ORM only when it makes sense to use it, instead of relying on ORMs as crutch for not knowing SQL.
The second approach seems better, but obviously SQL (power, performance, and prevalence) cannot be ignored.