Jump to: navigation, search

Difference between revisions of "Keystone/sql-migrate-extensions"

(Created page with "The migrations are performed monolithically, but the separate backends can actually be separately versioned. While this works fine for core, it will not work for extensions. ...")
 
 
Line 1: Line 1:
 
The migrations are performed monolithically, but the separate backends can actually be separately versioned.  While this works fine for core, it will not work for extensions.  We need to make it simple and clear how to do migrations for extensions.  The migrate_version table already supports this:
 
The migrations are performed monolithically, but the separate backends can actually be separately versioned.  While this works fine for core, it will not work for extensions.  We need to make it simple and clear how to do migrations for extensions.  The migrate_version table already supports this:
 
+
<pre>
mysql> desc migrate_version;
+
sql> desc migrate_version;
 
+-----------------+--------------+------+-----+---------+-------+
 
+-----------------+--------------+------+-----+---------+-------+
 
| Field          | Type        | Null | Key | Default | Extra |
 
| Field          | Type        | Null | Key | Default | Extra |
Line 9: Line 9:
 
| version        | int(11)      | YES  |    | NULL    |      |
 
| version        | int(11)      | YES  |    | NULL    |      |
 
+-----------------+--------------+------+-----+---------+-------+
 
+-----------------+--------------+------+-----+---------+-------+
 
+
</pre>
  
 
Each of the backends already support calling the central migrations via the db_sync mechanism.
 
Each of the backends already support calling the central migrations via the db_sync mechanism.

Latest revision as of 17:16, 14 May 2013

The migrations are performed monolithically, but the separate backends can actually be separately versioned. While this works fine for core, it will not work for extensions. We need to make it simple and clear how to do migrations for extensions. The migrate_version table already supports this:

sql> desc migrate_version;
+-----------------+--------------+------+-----+---------+-------+
| Field           | Type         | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| repository_id   | varchar(250) | NO   | PRI | NULL    |       |
| repository_path | text         | YES  |     | NULL    |       |
| version         | int(11)      | YES  |     | NULL    |       |
+-----------------+--------------+------+-----+---------+-------+

Each of the backends already support calling the central migrations via the db_sync mechanism.