[dev] Optional migrations

[Jan Schneider]

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

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

This is how I've implemented it with Shares now. The schema migration  
includes an initial data migration that could always be triggered  
again with a separate script. Downgrading doesn't touch the data, just  
removes the tables added during upgrades.

Jan.

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