Titanium JIRA Archive
Alloy (ALOY)

[ALOY-453] Fully support up and down migrations in sql adapter

GitHub Issuen/a
TypeBug
PriorityHigh
StatusResolved
ResolutionFixed
Resolution Date2013-01-17T20:04:56.000+0000
Affected Version/sn/a
Fix Version/sAlloy 0.3.5, 2013 Sprint 02
ComponentsRuntime
LabelsGA-candidate, notable
ReporterTony Lukasavage
AssigneeUnknown
Created2013-01-09T15:37:09.000+0000
Updated2018-03-07T22:26:00.000+0000

Description

When constructing a sql database from a series of migrations with no special parameters, we should assume that the latest migration is our target. With the latest migration as the target, we should call the up() function on all migrations before it (including the latest), starting with the last migration that has been executed in the app. down() functions should not be called unless a developer is rolling back a migration to an earlier one, for which we don't really have a method to do so yet anyway. This is not how it working right now in the sql adapter. The basic flow of applying migrations should be as follows:

Standard application flow, no explicit migration version specified

Get the "last migration" executed, which should be saved. Now it is being saved in the sqlite database, but if it doesn't exist it should be assumed that the first migration is the starting point.

Execute, in order, the up() function of all migrations from the starting migration to the latest migration.

Update the "last migration" in the sqlite database.

We should also add a way for developers to specify a specific migration to which they want their app to conform. We should add a parameter to the model config that allows them to pick that version:
exports.definition = {
	config: {
		"columns": {
			"name":"text",
			"nickname":"text"
		},
		"adapter": {
			"type": "sql",
			"collection_name": "fighters",

               // this field determines whether the database is up to date,
               // or if it requires an upgrade or rollback
               "migration": "201209301904312"
		}
	}
}
Notice the new migration field in "adapter". This tells the app which migration to conform to. The following shows the flow for upgrading and downgrading based on this version number.

config version same as "last" version

* Do nothing

config version is greater than "last" version

* Execute all up() functions, in order, on migrations greater than the "last" version and less than or equal to the config version

config version is less than "last" version

* Execute all down() functions, in reverse order, on migrations greater than config version and less than or equal to the "last" version

Comments

  1. Tony Lukasavage 2013-01-17

    Migrations testable up and down in: * https://github.com/appcelerator/alloy/tree/master/test/apps/models/sql_keywords * https://github.com/appcelerator/alloy/tree/master/test/apps/models/sql_preload * https://github.com/appcelerator/alloy/tree/master/test/apps/models/sql_queries

JSON Source