[dev] Optional migrations

[Jan Schneider]

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

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.

Thoughts?

Jan.

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