[dev] Optional migrations

[Michael Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

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

Maybe we need a generic way to separate out data conversion migrations  
vs simple schema migrations for instances when it's possible to switch  
back and forth between drivers? i.e.,The only time data migration  
should be included is when it's mandatory, like if the structure of  
one of the drivers changes, not when adding an additional driver. The  
automatic migrations would only add the new tables, and possibly run  
the initial conversion, while leaving the old data intact. An  
additional migration script could be provided to go from one driver to  
another. That way data conversions could be run separately, and  
wouldn't be counted towards the schema version. Maybe a post-install  
action could ask if the driver should be switched? Any additional  
*mandatory* data conversion would be put into the main-line  
migrations, and updated data conversion migrations could be provided.

mike

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