Implement Migrations

[elbrujohalcon]

a'lla Ruby on Rails :)

[elbrujohalcon]

@marcelog do you want to provide some guidelines on how to do this? Do you have some input on this subject?

[elbrujohalcon]

@igaray as well?

[igaray]

Such things are not small undertakings, a first approach might be to simply write migration scripts in SQL, and have the migration system merely manage which migrations have been run.

• easy to use commands should be available, e.g. sumo:migrate(), which does not depend on a running system (so that ops can script something like erl -s sumo migrate)
• a command to generate a version number for a migration or generate a migration template
• the database version would have to be stored and updated somewhere, possibly a file instead of a database
• migrations should have a set location in the project folder tree;

No:

• DSL for specifying schema changes
• automatic schema extraction and update

[jfacorro]

@igaray I agree with all the items in the previous comment except for the following:

the database version would have to be stored and updated somewhere, possibly a file instead of a database

Rails migrations stores the current version of the database (along with all migrations that have been run) in a table inside the DB itself, which I think is a lot cleaner than having a separate file, since the version information can't be unattached from the DB.

[jfacorro]

@elbrujohalcon @igaray A possible implementation could involve:

• sumo_migration behaviour: with the callbacks up and down. This two callbacks can either perform actions using sumo's API or they can just return SQL code that the sumo_migration behaviour then executes.
• sumo:create_migration/1: receives an atom that is used to create a new .erl file, whose filename is the concatenation of the atom and timestamp, and its content is a module with the scaffolding that implements the sumo_migration behaviour.
• sumo:migrate/0: runs all migrations to get the DB up to date.
• sumo:rollback/0: rolls back the last migration and downgrades the DB version.

If the DB version is stored in a DB table then sumo will check if the corresponding table exists, if it doesn't it can be an error or it could just get created.

[elbrujohalcon]

@jfacorro I like it, but I would let any code generation (number 2 in your list) for another issue. In this one I would just focus on letting devs write and execute migrations and providing something like sumo:create_schema that runs them (items 3 and 4 in your list).
Very generic, very simple for this initial version. We can improve later.

[elbrujohalcon]

@jfacorro On the other hand… I don't think any of the current functions on sumo will be actually used in migrations since all of them work with data and migrations are usually all about schema modifications.
On the other hand, a function that, given a sumo_doc schema, updates the db accordingly (i.e. adding missing columns or removing old ones or just creating the whole table in the db) seems useful. Maybe that can also be a in a new github issue