Re: [mantisbt-dev] I suggest we release Mantis 1.1.1

[Glenn H. <thr...@lo...>]

On 14-Jan-08, at 11:15 AM, Patrick Schoenfeld wrote:

>
> On Mon, Jan 14, 2008 at 10:56:53AM -0500, John Reese wrote:
>> To upgrade from 1.0.8 to 1.1.0, point at admin/install.php, which  
>> is the
>> new all-in-one install/upgrade system.  It will know how to properly
>> convert from the old version to the new.
>
> Instead of upgrade.php? Then login_page.php should be fixed, because  
> it
> points to upgrade.php.

   The login page should point to the appropriate upgrader. It checks  
for special data in the database to see what version the database is,  
and acts appropriately. The wording on the screen is the same in  
either case, but the underlying link is different.

   If you have a failing case, I would like a copy of the database to  
inspect.

>
> Besides that: That gives me install statements instead of
> upgrade statements (e.g. create statements instead of alter  
> statements)
> so this does not help much.

   The schema definition is incremental (see admin/schema.php).  
Developers use create or alter statements as appropriate.

>
>
>> For the future, raw SQL files will not suffice, as the path from  
>> 1.1.0
>> to 1.2.0 is far more complex, as the upgrade process changes the  
>> actual
>> database schema and structure using custom PHP functions to bring old
>> data up to the new standard.
>
> That sounds to me like it is broken by design. Is there no better way
> to do it?

   Not really. There are cases where the representation of data needs  
to change, The best place to convert the information is in the  
installer. The change John is alluding to is to enumerate, and convert  
strings representing categories to reference ids. There is no simple  
SQL only way of doing this (excluding stored procedures).

>
>
>> I should think there should be a way to have the .deb either load
>> up a browser to the correct URL, or for command line servers,
>> give the user a message telling them what URL to visit.
>
> Well, it is possible to spawn a php application, however that does not
> fit within dbconfig-common which is a common framework which a lot of
> applications in Debian share.

   Is there any documentation for dbconfig-common? The description  
page matches exactly what our installer does, except we handle MSSQL,  
Oracle, and db2 databases as well.

> All in all these solutions are workarounds
> anyway. It _must_ be possible to upgrade the database of a quiet  
> simple
> web application _without_ user interaction/unattended (besides  
> possibly
> things like charset translations).

   admin/install.php is generally unattended. The "go" button shows up  
to confirm the database location, and to allow the user to enter a  
second database userid to perform the upgrade (and enhance the  
security of the database.

> The downsides of spawning a php application
> should be clear:
>
> - all the error handling that is already done in dbconfig-common needs
>  to be replicated for the php-based method
> - you need to depend on a cli-variant of php (which I do not need now,
>  because suggesting it for people who want to use checkin.php and a
>  alike is enough)
> - its more error prone.
>
> All in all it is _not_ a good solution to depend on php functions to
> upgrade a database. And I don't think that it is required, as a lot of
> application out there are able to upgrade without this need.
>

   The php functions are intended to issue more complex and related  
SQL statements, that don't fit into the simple model of the schema  
language.

-- 
Glenn Henshaw                     Logical Outcome Ltd.
e: thr...@lo...     w: www.logicaloutcome.ca