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

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

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

But in my example, I can't get back down to 0.  So I can't drop the  
schema table.  Which means it won't let me migrate down to version 0.   
See the circular issue here?

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

They weren't (all) deleted - the schema table still existed.  But what  
if tables weren't deleted at all?  Or what if there was an issue  
recovering from a backup such as text being encoded incorrectly?  Or  
what if I decided to uninstall a package (e.g. VFS) that contained a  
SQL table?  Or what if I just simply wanted to clean out a table and  
start over again?

There needs to be some way to do all of these without resorting to  
manually logging on to the SQL server.

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

I'm not talking about migration.  I'm talking about recreating the  
database.  It may be called Horde_Db_Migration, but the fact is this  
is the *ONLY* way to presently create database tables in Horde.  There  
is no way to manually create a table.  So if something goes wrong, and  
something WILL go wrong, I am SOL without advanced PHP knowledge?   
Because what you are essentially asking from an admin is that if  
something goes wrong in a database, they need to visually parse the  
contents of a migration script to determine which tables to drop while  
also tasking them with the knowledge that a schema version table  
exists elsewhere in the database that also has to be altered.  So how  
is this not a giant step backward from H3?

I'm really asking for nothing more than a reset/clear command to  
horde/bin/db_migrate - a command that will essentially run ONLY the  
version 1 -> 0 downgrade no matter the current version of the schema.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]