[dev] Optional migrations

[Jan Schneider]

Zitat von Michael Rubinsky <mrubinsk at horde.org>:

>
> 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.

I disagree, if migration migrates data too, it should work in both  
directions. Besides that, this is getting ugly if this is not the  
latest migration step.

>> 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.

See above.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/