Open-RethinkDB meeting notes
docs.google.com
docs.google.com
RethinkDB is something we were looking at for a large project. In one way I am glad we didn't choose that platform for it, but in another way, the efforts by the open source community to keep it alive has given me confidence to revisit the platform for future projects.
From the comments in HN it feels like this was always the case for RethinkDB; folks looking at it, admire it, thinking about using it in their next project but, for one reason or the another, never ending up using it. Which is really a pity.
I don't know about the others, but I am really curious to know why you ended up not picking RethinkDB for your project.
In our particular case it is because I (as lead technical person on projects) come from a 30+ year background in SQL. Moving to NoSQL is always a point of trepidation for me purely form a comfort and familiarity angle.
I must say though, in our investigation of NoSQL systems for a couple of projects ReThinkDB (and PouchDB for another mobile project) were the two that seemed to stand out, and seemed to make installation and testing easy, as well as remove a lot of the barriers to dipping a toe in the NoSQL ocean.
So, end of the day it wasn't really a technology issue, but rather came down to familiarity and habits.
NB: For the mobile project, we went with Back& (backand.com) which is essentially a NoSQL wrapper around a MySQL database that we have running behind it. It helped me to get my head around NoSQL while still letting our DBAs build out the data structures in pure SQL. Working well so far.
The reason we ended up with Postgres over RethinkDB was that our data model was very relationship heavy in ways that were easier to represent in a relational database than with RethinkDB's document model.
Because we build business and ERP extensions most of the time, the requirement for multiple joins across sometimes up to 7 or 8 tables was what I found difficult to manage in NoSQL data stores. Foreign keys, LEFT OUTER JOIN, SELECT DISTINCT, GROUP BY etc. are all second nature to me in SQL, but totally Greek to me in NoSQL.
I guess I was talking about 'inadvertent' database changes. It seems that things like a simple typo can end up creating new attributes in a table when you didn't want it to, e.g. lets say earlier in my code, I have:
mytable.thisthing = 1
Then later on, someone mis-types:
mytable.thatthing = 2
I now have TWO attributes in my table instead of having the original "thisthing" attribute changed to 2.
An app with an SQL backend will usually throw an 'object/column not found' error if it recognises an attribute/column that is not on the original spec, but a couple of the NoSQL systems I've dealt with will happily take that line of code and work away with it, making debugging down the track a bit of a nightmare.
I am sure you can harden your NoSQL service to prevent this sort of thing, but then it becomes a question of whether the extra effort involved is worth it as compared to sticking with SQL where you are more constrained, but have better control over inadvertent table changes.
Just like you have your SQL schema defined in a central place, allow only a few select developers to make changes to it, and put any changes under extra scrutiny, you do the same when the schema is defined in your application code.
'.. but what if typos' is not a valid argument. Not in 2016. You can use code reviews, tools (compilers, static type checkers) and good software engineering practices to avoid problems due to typos.
I once worked on a system which consisted of about a half-dozen services and MongoDB. At some point we noticed that a large percentage of the documents in a certain collection had somehow had a Date field coerced to String, which caused a bunch of stuff to not work correctly.
That one took a while to track down.
Granted, it won't validate that the keys exist, however (since its schemaless at the DB level), so nothing will prevent you from inserting a document with foreign keys that are invalid, but from a querying point of view, foreign keys are easy. Would be nice if you could set insert/update-checked constraints though.
I'm really happy to see forward motion on this project though. It's the kind of thing I'd love to be involved in, if I were a completely different person.