[dev] Optional migrations

[Michael Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

> Does anybody have a bright idea how to implement optional Horde_Db  
> migrations?
>
> A perfect example is the new Share SQL driver that needs a different  
> table layout than the existing SQL driver. As with any new driver,  
> the two options are to:
> 1) Create new tables and keep the old ones for backup or to  
> potentially run both share driver side-by-side. This may include a  
> one-time copy-and-conversion of the old data to the new tables.
> 2) Update the existing tables and data in place.
>
> Back in the old times we let the admin decide when to run a  
> convert_X_to_Y script to migrate to a different backend. With  
> migrations this would happen automatically.
> Option 1 might be a good solution for that but the problem is the  
> one-time data conversion. If for example the new driver is going to  
> be tested, which is probably a common scenario, there is no way with  
> the current migration framework to re-run this migration at a later  
> point.

Couldn't migrate down be used to bring the schema version back, then  
rerun the migrate up operation? The migrate down operation shouldn't  
attempt to move any share data back to the original share tables, but  
shouldn't drop or delete from the original tables.

> Option 2 obviously requires that the configuration is changed at the  
> same time. It also determines that the migration has to be done at a  
> certain step in the migration sequence, i.e. it doesn't allow to do  
> the migration at a later point.

For an optional driver, this seems too final. i.e., Previously we were  
able to switch between using datatree or sql on a whim without losing  
data in the process.

>
> A solution might be to do this migration completely out of the  
> regular migration route, which kind-of defeats the purpose of  
> migrations and makes it difficult to later update those tables  
> automatically.

> Another solution could implement the first approach, but provide a  
> separate script to re-run (or even run at all?) the data conversion.

I think running the migration script automatically to create the new  
tables, and move existing data is a good approach, but the script  
shouldn't drop the original tables, remove or otherwise change the  
existing data. That way, if we revert to using the old driver, we can  
migrate share down, then rerun the migrate up.


mike

The Horde Project (www.horde.org)
mrubinsk at horde.org