[dev] Personal migration scripts

Jan Schneider jan at horde.org
Mon Feb 13 17:02:45 UTC 2012


Zitat von Gonçalo Queirós <goncalo.queiros at portugalmail.net>:

>    Citando Michael J Rubinsky <mrubinsk at horde.org>:
>> Quoting Gonçalo Queirós <goncalo.queiros at portugalmail.net>:
>>> If someone wants to make a migration script for Kronolith (ex), he will
>>>   have to look into the migraiton folder and create a new file with the
>>>   correct version number.
>>>   The problem is that this will only last until Horde creates a new
>>>   migration script, because after that, the migrator will refuse
>>> to migrate,
>>>   since it detects two files with same version number.
>>>   Is there anyway to circumvent this problem? I tried naming the
>>> file with a
>>>   float version number, but it didn't work, but i think it could be a good
>>>   solution.
>>  IMO, this is asking for trouble. If you run a local migration that
>> is not in the upstream codebase, you will run into a number of
>> prolems. As you discovered, the local migration will increment the
>> schema version so any future upstream migrations will not run. In
>> addtion, even if you could implement some form of floating numbered
>> migration versioning that would allow your migration to run, once
>> you modify the schema you no longer have ANY guarentee that future
>> upstream migrations will work correctly, since they rely on the
>> structure of the database to be known at any point in the version
>> tree.
>>
>>  My recommendation if you require local changes to the schema would
>> be for you to run custom sql scripts, possibly after each upgrade
>> since the schema of the database may change between versions.
>> ALternatively, you could of course attempt to submit your changes
>> upstream for inclusion :)
>>
> Don't think the changes will be accepted, since they are a bit divergent
> from what horde is doing :-)
>    I understand your point when you say that the scripts need to ensure
> that the db is in a certain state, but if i run my own custom scripts, the
> problem will still exist. I know that from the time i change the DB
> structure i will have to be very careful every time i upgrade the db using
> the new Horde migration scripts, but thats my responsibility.
>    I was just thinking that it would be nice to be able to use the
> Horde_Migrator to create this custom scripts :-)

Track your migrations in a separate application or framework package.
-- 
The Horde Project
http://www.horde.org/



More information about the dev mailing list