[dev] [commits] Horde branch master updated. 395a6e1f5eaf894889892e2d1c58f5bb71a22188

[Jan Schneider]

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

> --
> Mike
> Sent from my iPad...
>
> On Mar 24, 2011, at 7:37 PM, Michael M Slusarz <slusarz at horde.org> wrote:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>
>>>>>> -----------------------------------------------------------------------
>>>>>>
>>>>>> commit 5bf5caa8503b68b0f4b218f9f8c6a3d1ae98fad4
>>>>>> Author: Michael M Slusarz <slusarz at curecanti.org>
>>>>>> Date:   Thu Mar 24 14:58:11 2011 -0600
>>>>>>
>>>>>> These all break migrations if database doesn't exist
>>>>>>
>>>>>> framework/Vfs/migration/Horde/Vfs/1_horde_vfs_base_tables.php    
>>>>>>   |    9 +++-
>>>>>> .../Vfs/migration/Horde/Vfs/2_horde_vfs_upgrade_autoincrement.php |    
>>>>>> 11 +++-
>>>>>> 2 files changed, 15 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> http://git.horde.org/horde-git/-/commit/5bf5caa8503b68b0f4b218f9f8c6a3d1ae98fad4
>>>>>
>>>>> Why and when would you run a "down" migration if you don't even  
>>>>> have a database?
>>>>
>>>> You have a corrupt database/table and want to remove the table  
>>>> (which just happened to me).  There is no way to recreate the  
>>>> table unless the schema version is returned to 0, which can only  
>>>> be done this way.
>>>
>>> If you corrupted your database, you need to fix it manually. The  
>>> point of the migration scripts is that they *depend* on schema  
>>> version info being correct.
>>
>> Then this is a giant step backward.  Because I had *no* idea that I  
>> was also responsible for deleting a schema database that I was not  
>> even aware existed.
>
> I wouldn't call this a giant step backwards. IMO this isn't much  
> different the the old sequence tables that were automatically  
> generated.

With the difference that the schema tables already *are* being deleted  
when migrating down to 0.

>> We HAVE to provide a way to rebuild tables from scratch in this  
>> circumstance - especially since we no longer provide an SQL schema  
>> to be able to do this manually.
>
> Maybe I'm missing something here, but shouldn't the table be removed  
> via a down migration, instead of manually deleting it thus resetting  
> the schema version correctly?

Yes, exactly. From Michael's commit I assume that the VFS tables  
already were deleted, but the schema version was still higher than 0.  
So migrating down failed.

But:
1) This is not different from H3 migration style. We have to assume  
the current state of the database for upgrade scripts to properly work.
2) Depending on the schema version to be correct is an extra  
protection against corrupted databases schemas and helps *us* to make  
sure that the database is in a known state.

Jan.

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