
Rdb – a Node.js ORM with transactions, persistence ignorance and promises - lroal
https://www.npmjs.com/package/rdb
======
mackwic
Seems interesting ! I would definitely like more ORM for node.js technologies.

The concurrent are Sequelize
([http://sequelizejs.com/](http://sequelizejs.com/)) and Bookshelf
([http://bookshelfjs.org/](http://bookshelfjs.org/)), both very mature
libraries (look at the Sequelize test suite, it's quite impressing !). Iroal,
any comment on the rdb choices against these two big guys ? How can we expect
rdb to evolve ?

~~~
aselzer
And if you just want a flexible ORM without models, knex
([http://knexjs.org/](http://knexjs.org/)), which bookshelf uses.

I found knex + Postgres to be a great combination.

~~~
igl
I really really really like Knex. While Mongo claims to be "easy" and "js-
native", It's far easier doing complicated queries with Knex on Postgres than
on Mongo with the official client.

I work on a mongo project and doing aggregate queries is really ugly and
painful. Everyone praising mongo probably never made "advanced" queries like
that or dismissed SQL as shitty and unsecure without ever using it.

~~~
mgkimsal
What would be 'unsecure' about SQL? Not sure I ever heard that argument
before.

~~~
cwmma
unparamatarized queries are the usual issue, so not an issue with sql as much
as how people misuse sql.

------
distracteddev90
Any chance Rdb plans to support a traditional callback style interface for
those of us that prefer to stay away from promises?

~~~
lroal
My plan was to stick to promises only. Unless there are lots of lots of
developers that really wants callbacks.

~~~
phpnode
please stick with promises. Promises are the only sane way to deal with async
in JS. With people starting to use async/await they become even more
compelling.

The people who defend callbacks either don't understand the benefits that
promises provide, don't know about async/await or are suffering from stockholm
syndrome.

Callbacks do not pass the reversibility test. If everyone had started out with
promises and / or async/await, and someone proposed callbacks as a way to deal
with this instead, they'd be dismissed as a fool. They're an accident of
history and we should forget about them as quickly as possible.

~~~
doublerebel
Callbacks allow await/defer in Iced CoffeeScript, not to mention the other
async libs as stated above.

Promises don't really offer any benefit to program structure overall,
generally devs just end up creating long chains of anonymous functions rather
than long nests of anonymous functions. Promises actually discourage flat code
(and functional programming) for that reason. I understand they seem
attractive but become a hack in complex situations.

~~~
phpnode
> Callbacks allow await/defer in Iced CoffeeScript

Not the same thing as in ES6, also that project is totally dead.

> generally devs just end up creating long chains of anonymous functions
> rather than long nests of anonymous functions

Not true in my experience, also not required at all when using async / await.

> Promises actually discourage flat code (and functional programming) for that
> reason.

This is really not true, Promises are functional and composable, callbacks are
imperative.

> I understand they seem attractive but become a hack in complex situations.

Just no. Callbacks lead to terrible "solutions" like caolan/async, callbacks
make refactoring extremely awkward.

Callbacks don't even get to claim better performance, because they require a
load of internal hacks in node/io.js to maintain state.

With async/await in the picture, callbacks so totally inferior I can't believe
someone would attempt to argue otherwise.

------
k__
Nice.

I'm currently checking out ORMs for node.

What I found was Bookshelf, Sequelize and Jugglingdb.

I think Rdb needs SQLite support for development purposes and smaller
projects.

~~~
lroal
Agree

------
joshuakarjala
Is anyone working on auto-generated migrations in node.js ala. Django / South?

~~~
distracteddev90
I believe Sequelize does this:

[https://sequelize.readthedocs.org/en/latest/docs/migrations/](https://sequelize.readthedocs.org/en/latest/docs/migrations/)

~~~
bulkan
No it does not do this yet. See this issue [1]. The db:create task in the
sequelize cli only creates a new stub migration file.

1 -
[https://github.com/sequelize/cli/issues/8](https://github.com/sequelize/cli/issues/8)

------
sehrope
Does this allow users to execute custom SQL, in addition to ORM methods, and
have it be part of the same transaction?

~~~
lroal
It is not supported today. But it would't be any problem to implement it.
Please create an issue if you want it.

------
rattray
Not sure I see the advantage over waterline
([https://www.npmjs.com/package/waterline](https://www.npmjs.com/package/waterline))
?

~~~
onestone
Waterline is a joke, it doesn't even have transactions.

------
bonn1
ORMs are not really required in a Node/Mongo/JSON setup anymore:

\- JSON's nature is already very 'object oriented' and I use in code JSON data
like it saved—no translation beetween clunky SQL and objects is necessary (if
I have a DB which saves JSON natively like Mongo)

\- Mongo allows to directly save JSON and stuff like migrations is stuff from
the past since tables/collections don't have to be created

\- Mongo's Native Driver is low level and at the same time fully sufficient,
the syntax is not beautiful and tons of libs sit on top to make it beautiful
but I still don't see the need for a real ORM

So, Mongo's Native Driver is your best friend and validations are often a
matter of a few lines. Or did I miss anything which is life saving I get from
ORMs in a Node/Mongo setup?

~~~
joshuakarjala
Not everyone is only using Mongo with Node

~~~
bonn1
Good point and I just checked: rdb seems to be for SQL based DBs.

But I am wondering who is using SQL based DBs with Node, feels ancient to me,
except you build the next datastore for a bank but even then. Also Postgres
with its JSON options does not give the feeling, flexibility and speed as
Node/Mongo.

I could imagine that the larger part of Node users are working with Mongo, or
not?

~~~
distracteddev90
Mongo is great for when you're rapidly developing a product and/or still
operating at a small-medium scale.

Once you start to really scale, you'll start to find a couple parts of MongoDB
break-down:

1\. MongoDB has no concept of transactions and is not ACID compliant. These
short-comings seem innocuous enough at first, but you end up with some crazy
potential race conditions that you just end up praying you never face.

2\. Distributed MongoDB layers are difficult to implement as well as maintain.

3\. MongoDB Replica sets are unpredictable and unreliable in the speed at
which they are able to stay up to date and require changes to your code to
fully utilize (since you need to ensure you are always reading from a replica
when you can, but only ever writing to the master MongoDB instance)

4\. At scale, MongoDB will consistently perform worse than Postgres for CRUD-
based operations

5\. Do you have true relations between documents? Do you ever use Mongoose's
convenient `populate()` functionality? If so, you are now making multiple db
queries in series when trying to fetch a document(s) from a single collection.
This starts to really hurt your query times once you get enough
documents/relations in your mongo collections.

I'm sure I'm missing some, but these are some of the areas where MongoDB has
fallen down for me in the past.

~~~
tragic
> Mongo is great for when you're rapidly developing a product and/or still
> operating at a small-medium scale.

Yesterday somebody from a node-based consultancy gave a talk at work about
microservices, where he remarked in passing that they tend to start projects
with mongo, then wait for a schema to kind of 'fall out' of the application as
it takes shape, and then switch to postgres or something. Which doesn't seem
like an awful idea.

