[dev] Personal migration scripts

[Michael J Rubinsky]

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 :)

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6096 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20120207/a6976c58/attachment.bin>