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

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

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

No. :) You can't migrate down to 0 *if* you drop the schema table, not  
if you *can't* drop the schema table. Thus I don't really understand  
what you are saying, or at least not the logic behind it.

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

If you want to start over again, just delete all tables, including the  
schema table.

Also, I don't understand the issue if only the schema table was not  
deleted. As long as it contains 0, it doesn't matter if it exists or  
not. The change you introduced only catched if deleting two certain  
tables, in a certain migration step, in a certain direction, failed.

The other points don't make sense to me either. What's the problem  
with uninstalling a package? Either you migrate the package down  
before deleting, or you don't care and leave the tables. If you later  
re-install the package, you can either pick up from that state and  
upgrade to the latest version, or start from zero if deleted the  
tables during uninstall.
And what does incorrect encoding have to do with this?

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

Why should something go wrong? And how is this different from H3 where  
things could go wrong with SQL scripts too, which happened all the  
time. The user ended up with inconsistent, broken database state. They  
then had two options. Either they were experienced administrators that  
could make sense of the error, figure out how to fix it, and updated  
the database manually. They can still do this with H4. Or they were  
lost. And those still will be with H4.
But since the point of migrations is that we no longer have to know  
about all the details and oddities of different DB systems and  
versions to change a database structure, error are less likely to  
happen with migrations than with manually created SQL scripts. That's  
a giant step forward.
May there be bugs in Horde_Db_Migration? Sure, but that's not  
different from any other bug in Horde that may lead to inconsistent  
data.

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

See what Michael said. This would make things worse.

What I can see us adding is some extra information to the migration  
classes about any tables that may potentially be added for an  
application. Then add some migration feature that would delete all  
those tables (if they exist, no questions asked if not) and the schema  
table. Though I wonder how often this really would be used, because  
potentially, the user will lose *any* data with this feature, instead  
of being left with some inconsistent data that he might be able to fix  
with the help of the mailing list.

Jan.

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