[AC-2503] Alloy: Migrations bugs
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | n/a |
Status | Closed |
Resolution | Needs more info |
Resolution Date | 2013-07-23T22:02:25.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | Alloy, Appcelerator CLI |
Labels | Backbone, Models, adapter, migration |
Reporter | Mads Moller |
Assignee | Shak Hossain |
Created | 2013-07-12T11:51:39.000+0000 |
Updated | 2016-03-08T07:41:33.000+0000 |
Description
Hi Tony,
I have two bugs regarding migration in Alloy.
*Bug/unexpected result 1:*
When doing a migration with the *sql* adapter, the script fails when executing migrations on first run on a fresh installed app. This is because the migration script will go through each migration, without creating the table beforehand. Hence, the first migration MUST include the definition of the table. e.g.
migration.up = function(migrator) {
migrator.createTable({
"columns": {
"id": "INTEGER",
"title": "TEXT",
"icon": "TEXT",
"type": "TEXT",
"parent_id": "INTEGER"
}
});
migrator.db.execute('ALTER TABLE ' + migrator.table + ' ADD COLUMN sort INT;');
};
But this is not logical. In my opinion the best approach would be to have the adapter create the table if it does not exists and afterwards go through all the migrations. In this manner, the above migration should only be:
migration.up = function(migrator) {
migrator.db.execute('ALTER TABLE ' + migrator.table + ' ADD COLUMN sort INT;');
};
Make sense?
*Bug 2:*
This might be a tooling issue, but here we go.
When I want to create a new migration for a model, its not possible because it already have a migration. This is wrong, because the migrations are controlled by timestamps, so its the idea to have the same name. Please look at the attachment migration.png.
Attachments
File | Date | Size |
---|---|---|
migration.png | 2013-07-12T11:51:39.000+0000 | 25994 |
1. I don't know, I think I prefer the usage of migrations to be explicit. If you don't use migrations, the table will be created automatically. If you do use migrations, the assumption is that you should handle things manually as you may need to do something before you even create the table. I don't think that's one I'm going to change, but if you have a more compelling argument I'm all ears. 2. This would be a TISTUD issue, as this is definitely not a limitation imposed by Alloy. I will bring [~mxia] into the conversation so that he can get it addressed in Studio.
The No. 2 is covered in TISTUD-2300 and fixed for the upcoming 3.1.2 release. If you would like to update to it now, you could use the update site http://preview.appcelerator.com/appcelerator/studio/standalone/update/beta/.