Database migrations

[nrempel]

Hi there,

In SailsJS, it was clear that it was up to the developer to write and maintain their own database migrations.

I find it a massive productivity boost to have the ability to generate migrations based on model changes or at the very least have a built-in migration runner. Does Trails have any plans for supporting database migrations or is this considered a separate concern?

Thanks.

[jamemackson]

:+1: I would love to see this baked right in as well.

[jaumard]

:+1: it would be nice to have this feature

[rmzr7]

+1

On Wed, Jan 6, 2016 at 4:27 PM, Jaumard [email protected] wrote:

[image: :+1:] it would be nice to have this feature

— Reply to this email directly or view it on GitHub https://github.com/trailsjs/trails/issues/68#issuecomment-169468334.

[tjwebb]

@nrempel I know right!

The alpha release will not include any migrations support. Since Trails supports many ORMs (Waterline is just one of them), we will reply on integrating a trailpack with something like node-db-migrate. This is something the core team is very interested in supporting, but we won't have support for it out of the box initially.

[mikehostetler]

Reopening this issue, as I'm looking for a solution.

Node.js best practice looks to be to use db-migrate (https://github.com/db-migrate).

What I'm chewing through is how best to integrate this with Trails. I'm looking for suggestions.

DB Migrate uses a custom CLI to power migrations. You can override this and include db-migrate as a module, and run your own custom CLI (https://db-migrate.readthedocs.io/en/latest/API/programable/#start-the-cli-mode) but Trails doesn't ship with a CLI and I don't think we want to re-write all of the methods.

Any suggestions?

I'm happy to take a stab at implementation on this, but I'd prefer to get some input on where I should hook in before I start digging into this.

[mikehostetler]

So, I have an idea.

I don't think building a separate trails CLI executable is a good move for the framework, but we do need something to hook into to handle the DB migrations.

Node best practice is to use NPM scripts, but those are limited, or so I thought. I just found https://github.com/FormidableLabs/builder which could help solve the Trails DB migration problem.

We can extend the Trails Yeoman generator to write migration scripts into package.json, which tie right into the Trails config, that directly use DB migrate, all pulled together with Builder.

I'm going to work up a proof of concept to see if I can get this to work.

[jaumard]

It may work but why not just have a trailpack that take the package.json version number and execute up/down from db-migrate accordingly before the trailpack ORM. Like this it's more easily maintainable for the team as it's just a trailpack that manage that. Also FormidableLabs/builder work with npm but what if you use yarn ? Or other package management.

[jaumard]

as @JAertgeerts say on Gitter https://github.com/sequelize/umzug can be a good solution instead of db-migrate because it works with stores (they call them storage). Witch this mean that each trailpack ORM can create and embed his migration storage, then trailpack-migrate or whatever can use this store/storage directly to do the migration :) good way to provide migration to all ORM without headache and maintenance nightmare.

What do you think ?

[maissani]

Hi @everyone. My opinion is that trails-migration should embed the selected orm migration sollutiion or if ORM less does not include migration solution ( if you use Waterline => Waterline migrate , if you use sequelize => umzug , etc...., if no orm => no migration up or down) Migrations should be in a directory and always handle trailpack::migration::up (with alias migrate) trailpack::migration::down (with alias rollback).

Have a nice day.

[jaumard]

@maissani it's not possible to trailpack-migration to embed only the selected ORM, it should contains all of them and use the correct one... witch will be a nightmare to maintain because nobody know all ORM and the way they're working. I prefer each trailpack ORM embed his own migration up/down system and trailpack-migrate just use it. umzug offer a unified interface to do it for all ORM that's why I think it's a good idea to do it with it. But we can create a interface for all ORM and use it with db-migrate also... but it's more work ^^