rake-db naming

[capaj]

why is rake-db named as it is?
It almost seems like unrelated package, yet it shares the same schema definitions and from the docs I assume it's the recommended migration tool.

Wouldn't orchid-migrations or something like that be a better name for that package? Or maybe creating an org for orchid orm? That way it could be on npm under @orchid/rake-db

[romeerez]

Nice question, it reminds me of the time when I was switching to node.js!

So I was Ruby on Rails dev for years, there were things that I love, but much more pain that caused me to promise myself to never again touch any Ruby code, and I switched to node.js because it's much less magical, simpler, has much more freedom, plays better with JSON, actually there are many things that I love in node.js. And later we met with TS and it was a crush.

After switching to node.js, I quickly realized that there is a wild-west going on, it is missing many packages, many cool features that existed in RoR for decades.

The biggest thing that I miss is a good ORM because ORM in RoR was brilliant, and the Orchid ORM is partly inspired by ActiveRecord in RoR.

These methods in Orchid are named in the style of ActiveRecord:

db.model.all() // find all
db.model.where({ key: 'value' }) // find many with conditions
db.model.find(1) // find one by id
db.model.findBy({ key: 'value' }) // find one by key value

// it's also from ActiveRecord, not present in other node.js ORMs:
db.model.pluck('column') // get array of values

While typically in node.js ORMs they name methods similar to this:

db.model.find() // will find all
db.model.findOne() // will find one

So right after switching, I quickly realized that there is nothing in node.js ecosystem for databases that is any close to what RoR has, and started to do it myself since it seems no one else is really interested.

The first library was pg-adapter, which is an alternative for node-postgres. I planned to use it later in other packages. I'm not sure if there were any good reasons to develop it, but it was an interesting experience, and it's more efficient than node-postgres. This package is not used now, because between a bit faster library and fewer projects to maintain I chose the latter. But for the future, I have one idea of how to build an even much faster lib for this purpose. Because pg seems to be a bottleneck in my benchmarks, I inspected code with a debugger and found out that most of the time is spent there.

And the second library was rake-db, it's named after rake db command in Rails, here is the answer.
Just like in Rails, write only code for up and it will do down automatically, there is no other migration tool in node that can do that.

rake-db had a syntax that is close to Rails, I changed that later when was integrating Orchid ORM columns. Also rake-db was adding id columns automatically as Rails does, I removed that later because of not the best idea.

And then I started building my ORM: here is it, click "show depreciated versions" to see that the first version was 3 years ago. I thought the name is funny, but people didn't think so and convinced me to change it. I like the new name anyway.

Later I added a package for tests: pg-transactional-tests, and it's also inspired by how tests in Rails were clearing db implicitly with some hidden magic.

The package for creating objects shares the idea of what Rails have (factory-bot).

It almost seems like unrelated package

I wish to promote it in a standalone way later. Right now, the migration tool that supports only Postgres, is not enough, but later it will support different databases.

And then it could replace knex migrations! The best thing about rake-db is that it can generate migration files out of database, knex cannot do that AFAIK. And it's a problem and happens to me personally on work projects, when someone before wrote a project with Sequelize completely without migrations, I have to add migrations and have to look into the db schema, and write them manually.

And rake-db is very TS-friendly, I integrated knex migrations in TS projects not so long ago and it's not very good.

It has a better syntax, a single change instead of up and down.

So I think it can have a use as a standalone package on projects where people have Sequelize or other ORMs and query-builders that don't help much with migrations.

Or maybe creating an org for orchid orm?

orchid is taken (there are no packages in npm under @Orchid, but the org exists), and derivatives are not looking as good, so I'm just leaving it as is.