Re: [mantisbt-dev] Database initialization scripts

[<pa...@qu...>]

This is getting top quoted as it's in some silly web interface atm (at
1280x1024, i'm pretty sure you can make a web based email client that has
a box for the body with >10 lines and 30 chars wide)....

To me, this all seems to come down to ~2-3 basic problems with the current
approach:

Over time, we've done or tried doing the following:
i) Mantis moved from a native .sql file to a more automated approach. ii)
Mantis tried adding support for multiple DB's. iii) Mantis started using
adodb.

I dont think mantis is alone in bundling a webbased installer - The
installers i'm thinking of currently are those that come with two
applications: a) moodle (fairly large, I suspect it's in debian?) b)
fudforum (maybe not?). I'd be interested what approach debian take with
these as they a) support multiple DB backends, b) provide some level of
automated routine for updates. It might be we can learn from this
approach...

One thing I think we lack or could improve on is the way we currently
allow people to 'print sql queries' -> We have functionality to allow sql
queries to be printed out, atm, only accessible via a web interface after
logging in. This functionality should probably be available by some
command line means. (i.e. php cmd line script not some wget install.php
hack)

The second thing is adodb. Adodb seems to have a number of cases where the
datadict support (which is what the update stuff uses) is lacking some
functionality or is inconsistent. I know i've recently reported some
postgres stuff on their forum, and from our wiki page (
http://wiki.mantisbt.org/doku.php/mantisbt:adodb_fixes?s=adodb) someone
working with zend/IBM emailed the adodb guy(s)? about DB2. I think the
current case is none of the issues reported have been fixed in an adodb
release. In my case, the postgres stuff was submitted recently, and i've
yet to receive any feedback (<1 week ago).

>From a mantis perspective, it's not "a problem" as we can patch the
bundled adodb with any bug fixes. However, i'm not sure where that leaves
say  debian + mantis running on DB2 if they dont want to use the bundled
adodb but instead a global package, and adodb haven't responded to bug
reports.

Paul

> Hi John,
>
> On Mon, Apr 28, 2008 at 10:17:26AM -0400, John Reese wrote:
>> Please don't interpret this as an attack of any sort.  As a major
>> proponent of the Debian/Ubuntu distros, I would love to see Mantis reach
>> those users more easily.  This is just me pointing out all the hurdles I
>> see with what you are trying to accomplish.
>
> I don't interpret it as a attack. But I interpret the behaviour as
> throwing stones in my way. Because I'm doing what I can to near myself
> into your direction. I try to understand your problems, but you seem to
> offend the simplest solution from your developers point of view, while I
> try to
> make it simple for the users AND keep things sane for Debian.
>
>> Anyways, the real problem with pure SQL based setup is that We support
>> too many database types to make this feasible.  As you may have noticed,
>
> You don't seem to have read properly what I've written. I did not talk
> about a pure SQL based setup. I didn't say: Give me an SQL script that
> works on every database you support (well, btw. it seems that the only
> properly supported database is mysql if I look at the bugtracker and the
> second mail I wrote, so the "we support so many databases" argument is
> limited in its extend). What I said is: Give me an upgrade script that I
> can use non-interactive from within scripts (e.g. as a PHP script) and
> give me a tool to create SQL dumps _for the *initial* *creation*_ of the
> database. I understand all the arguments you have for upgrade problems.
> So I say: Okay, I'm able to come one step closer to you, but you have to
> come a step closer to me, too. Thats what I lack to see, currently.
> But the creation is totally different from that. Yes, you are true. The
> file formats are different, thats why I said give me a tool that dumps
> sql scripts given a specific database. I would be able to commit to even
> use a php script for the creation of the database, but I don't see where
> the benefit is in that, except that the process of creating the mantis
> database becomes a lot more non-transparent then it is now. Thats why
> I'm "voting" for "pure" SQL in this step of story.
>
>> The end result is that Mantis *can't* easily be simplified like you want
>> it to, because there are too many possibilities.  The only thing I can
>> think is to create a special system that uses AdoDB to interpret the
>> shorthand and transform it into raw SQL for each database type, and then
>> save those queries.
>
> Thats more or less what I asked for. Well, that does not help me in the
> short run, because I'm in pressure to create a current package, but it
> would help me in the long run. For now I would just need a
> create_database.sql for PostgreSQL and MySQL (because on Debian I will
> not support more DBMS) and a fix for the issue with old Debian
> installations,
> but that last thing is a thing that I have to do.
>
>> However, as has been mentioned previously in the mailing list, because
>> Mantis strives for such far-reaching backward compatibility, while still
>> making large changes to the infrastructure of the schema, we need
>> upgrade functions that are written in PHP as well, so that we can
>> smartly process and upgrade old information into the new system of
>> storage.  Case in point: category -> category_id upgrade path.  So this
>> sort of thing would definitely need to be taken into account when
>> handling upgrades versus new installs via any fedora/debian packages.
>
> See above. A transition is _not_ part of a new install, so this argument
> is invalid. I agree with you for upgrades. See my above comments.
>
> Regards,
> Patrick
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>
>