[dev] DB Migration questions

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

>>> There is still another "problem" though. Upgrade scripts in  
>>> development vs. stable versions. I suggest that we do it similarly  
>>> like we do it now. We just have to keep track of schema versions.  
>>> Example:
>>>
>>> In dev version:
>>> 4_add_some_missing_index.php
>>> 5_add_a_new_column.php
>>> 6_drop_another_one.php
>>>
>>> This should be a single script in stable versions, but the schema  
>>> version must match. I suggest that we even round the number up to  
>>> the next tens. This looks cleaner and could even help for debugging:
>>>
>>> 10_app_x_to_y.php
>>
>> I agree it is cleaner, but I don't think it is terrible if we have  
>> a bunch of small scripts either.  It actually makes things clearer,  
>> and might be easier to debug for an admin (if the DB upgrade fails  
>> in schema update 5, for example, that might be easier than trying  
>> to figure out where it failed within jumbo script 10).  It will be  
>> easier to backout changes also if using the smaller developer  
>> scripts.  In other words, I don't see a pressing need to create a  
>> release version of the schema scripts - it seems like it is just  
>> going to add more complexity when building a release.
>
> Makes sense, this would only be for cosmetical purposes anyway. Even  
> with a bunch of upgrade scripts, the admin still only has to run a  
> single script. Or no script at all.
> We could actually easily detect from the config overview whether an  
> application has an outdated db schema (like we show the outdated  
> configuration already), and have them updating their schema with a  
> single click.

Yes, yes, yes. :)

-chuck