From: John R. <jr...@le...> - 2008-01-14 14:39:26
|
I've noticed many people having problems with the 1.1.0 release of Mantis due to the stripos() function breaking PHP4 compatibilty. Rather than constantly pointing people at the SVN branch with the PHP4 fix, I think it would be rather beneficial to make an official 1.1.1 release featuring this. It would also give a good excuse to make an official test of the new packaging script. Cheers -- John Reese LeetCode.net |
From: Victor B. <vb...@gm...> - 2008-01-14 15:04:58
|
I agree that we should be releasing 1.1.1 asap, this is to avoid having people install Mantis 1.1.0 (stable) and right away get hit with the stripos error, which doesn't look good! However, I need to fix an introduced error into the SOAP API before I cut the release. http://www.mantisbt.org/bugs/view.php?id=8683 Let me know if anybody else is working on an issue that needs to be resolved before 1.1.1. On Jan 14, 2008 6:39 AM, John Reese <jr...@le...> wrote: > I've noticed many people having problems with the 1.1.0 release of > Mantis due to the stripos() function breaking PHP4 compatibilty. Rather > than constantly pointing people at the SVN branch with the PHP4 fix, I > think it would be rather beneficial to make an official 1.1.1 release > featuring this. It would also give a good excuse to make an official > test of the new packaging script. > > Cheers > > -- > John Reese > LeetCode.net > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Patrick S. <sch...@in...> - 2008-01-14 15:35:06
|
Hi Victor, On Mon, Jan 14, 2008 at 07:04:55AM -0800, Victor Boctor wrote: > Let me know if anybody else is working on an issue that needs to be > resolved before 1.1.1. I'm not "working" on this. However I have the feeling that upgrade path is not working properly (but it may be my failure as well) so it would be great if someone could have a look at my previous mail. Best Regards Patrick |
From: John R. <jr...@le...> - 2008-01-14 15:56:47
|
Patrick Schoenfeld wrote: > Hi Victor, > > On Mon, Jan 14, 2008 at 07:04:55AM -0800, Victor Boctor wrote: >> Let me know if anybody else is working on an issue that needs to be >> resolved before 1.1.1. > > I'm not "working" on this. However I have the feeling that upgrade path > is not working properly (but it may be my failure as well) so it would > be great if someone could have a look at my previous mail. > > Best Regards > Patrick 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. 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. 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. Hope this helps. -- John Reese LeetCode.net |
From: Victor B. <vb...@gm...> - 2008-01-17 08:48:52
|
I've fixed all the bugs that I believe qualify for the 1.1.1 release. I've also updated the Mantis Demo (which runs on PHP4) and Mantis Bug Tracker @ mantisbt.org (which runs on PHP5). The upgrade looked fine. If no issues arise in the next day or two, then I will cut the release. I would appreciate any help with testing. The scenarios I haven't covered yet are upgrade from 1.0.0 and fresh install. On Jan 14, 2008 7:04 AM, Victor Boctor <vb...@gm...> wrote: > I agree that we should be releasing 1.1.1 asap, this is to avoid > having people install Mantis 1.1.0 (stable) and right away get hit > with the stripos error, which doesn't look good! However, I need to > fix an introduced error into the SOAP API before I cut the release. > > http://www.mantisbt.org/bugs/view.php?id=8683 > > Let me know if anybody else is working on an issue that needs to be > resolved before 1.1.1. > > > On Jan 14, 2008 6:39 AM, John Reese <jr...@le...> wrote: > > I've noticed many people having problems with the 1.1.0 release of > > Mantis due to the stripos() function breaking PHP4 compatibilty. Rather > > than constantly pointing people at the SVN branch with the PHP4 fix, I > > think it would be rather beneficial to make an official 1.1.1 release > > featuring this. It would also give a good excuse to make an official > > test of the new packaging script. > > > > Cheers > > > > -- > > John Reese > > LeetCode.net > > > > ------------------------------------------------------------------------- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > _______________________________________________ > > mantisbt-dev mailing list > > man...@li... > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > |
From: Vincent D. <vin...@mo...> - 2008-01-17 09:26:44
|
Hi, I think that, for compatibility issues, it would be great to fix this issue: <http://www.mantisbt.org/bugs/view.php?id=8744> Regards, Vincent > I've fixed all the bugs that I believe qualify for the 1.1.1 release. > I've also updated the Mantis Demo (which runs on PHP4) and Mantis Bug > Tracker @ mantisbt.org (which runs on PHP5). The upgrade looked fine. > If no issues arise in the next day or two, then I will cut the > release. > > I would appreciate any help with testing. The scenarios I haven't > covered yet are upgrade from 1.0.0 and fresh install. > > On Jan 14, 2008 7:04 AM, Victor Boctor <vb...@gm...> wrote: >> I agree that we should be releasing 1.1.1 asap, this is to avoid >> having people install Mantis 1.1.0 (stable) and right away get hit >> with the stripos error, which doesn't look good! However, I need to >> fix an introduced error into the SOAP API before I cut the release. >> >> http://www.mantisbt.org/bugs/view.php?id=8683 >> >> Let me know if anybody else is working on an issue that needs to be >> resolved before 1.1.1. >> >> >> On Jan 14, 2008 6:39 AM, John Reese <jr...@le...> wrote: >> > I've noticed many people having problems with the 1.1.0 release of >> > Mantis due to the stripos() function breaking PHP4 compatibilty. >> Rather >> > than constantly pointing people at the SVN branch with the PHP4 fix, I >> > think it would be rather beneficial to make an official 1.1.1 release >> > featuring this. It would also give a good excuse to make an official >> > test of the new packaging script. >> > >> > Cheers >> > |
From: Jeferson O. <jef...@gm...> - 2008-01-18 11:59:03
|
Vincent DEBOUT wrote: > I think that, for compatibility issues, it would be great to fix this issue: > <http://www.mantisbt.org/bugs/view.php?id=8744> I also would appreciate the possibility of define a bug_set_priority_threshold in the config file. Regards, Jeferson Oliveira Brazil Enviado pelo Mozilla Thunderbird http://br.mozdev.org/thunderbird |
From: Patrick S. <sch...@in...> - 2008-01-14 16:15:37
|
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. 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. > 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? > 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. 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). 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. Regards, Patrick |
From: John R. <jr...@le...> - 2008-01-14 16:50:52
|
Patrick Schoenfeld wrote: >> 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? The problem stems from a rather major shift in how categories are handled in the system, going from simple strings passed all over the place to actual entities with ID's and such. The actual schema changes are made via SQL, but PHP functions are interleaved so that the old data can be converted throughout the application to the new format, and then SQL is used to remove the old schema. For compatibility and simplicity reasons, there is no sane way to perform this same action across multiple database vendors and variants while sticking to raw SQL statements. This is why we have the PHP functions to do this. >> 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. 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). 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. I don't think using a PHP cli is the answer either. I'm suggesting that the .deb point to the http://localhost/mantis/admin/install.php page so the user may perform the necessary upgrade procedures. Relying on a CLI upgrade was never suggested, and I would definitely not recommend it. But as it is, most of those other applications don't support the myriad of systems, databases, and other environments that Mantis does, so their upgrade steps are much simpler to perform. Not to mention that most other applications generally wouldn't even think of supporting an raw SQL-only upgrade process for a schema shift as large as this, so I don't think we're the only making choices like this. IE, Olympus has an automated upgrade path from phpBB2, but it's not an SQL-only upgrade, and it certainly is no simpler or easier to handle than what we're discussing here. -- John Reese LeetCode.net |
From: Patrick S. <sch...@in...> - 2008-01-14 19:34:35
|
Hi, On Mon, Jan 14, 2008 at 11:50:39AM -0500, John Reese wrote: > Patrick Schoenfeld wrote: > > That sounds to me like it is broken by design. Is there no better way > > to do it? > The problem stems from a rather major shift in how categories are > handled in the system, going from simple strings passed all over the > place to actual entities with ID's and such. The actual schema changes Okay, I understand. So basically something (when designing the mantis database) went wrong in the past and is to be fixed then. But you don't do that regular, right? Things like this should not occur too often, because things loose their simplicity by this. However: Is there a chance to make this upgrade two-phased, so that a part of the upgrade can be done as usual as a series of sql statements to the database and the rest - migrating the critical parts of the database to its new structure - afterthen in the upgrader? Next version could then use a sql-statement-based variant, which is really easier to use in a distribution. > For compatibility and simplicity reasons, there is no sane way to > perform this same action across multiple database vendors and variants > while sticking to raw SQL statements. This is why we have the PHP > functions to do this. Yeah, now I understand that. But anyways this task is not done often or shouldn't be done often, therefore I see no reason to take this as the reason for a major design change that will make things *much more* difficult and/or worse for distributors. > I don't think using a PHP cli is the answer either. I'm suggesting that Okay. Then I understood you wrong. > the .deb point to the http://localhost/mantis/admin/install.php page so > the user may perform the necessary upgrade procedures. Well, thats okay for seldom upgrades as this one is. But I think its neccessary to work out a way that is better integrated into the package configuration system, because thats more comfortable for a user of a specific distribution. Simply because it makes it more easy and less error-prone. However I must commit that there are situations where its not possible to do so. The one you are facing for 1.2.0 is probably such a situation, but I can only repeat myself to say that it should not be used as the basis for a major design change reason. > Relying on a CLI upgrade was never suggested, and I would definitely not recommend it. Right. Instead you recommend to let the user get a browser and perform the neccessary upgrade steps independent from the normal debconf system. If he wants to install things unattended: He can't, because he needs to hit a stupid ok button. > But as it is, most of those other applications don't support the myriad > of systems, databases, and other environments that Mantis does, so their > upgrade steps are much simpler to perform. Not to mention that most You are not the only one using adodb. In fact most current web applications do. The problem you have is not, because you are supporting so much of different systems or so, but that something went certainly wrong in the past. Fullstop. Please don't get me wrong. I don't want to bash what you and the other developers do, but by such *decisions* you make my life as a packager a lot harder then it would need to be. Also you are wasting users time, if you force them to do additional steps, that I could have done for them during the package configuration, for no reason. Best Regards, Patrick |
From: Glenn H. <thr...@lo...> - 2008-01-14 16:53:49
|
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 |
From: Patrick S. <sch...@in...> - 2008-01-14 19:58:10
|
Hi Glenn, On Mon, Jan 14, 2008 at 11:53:31AM -0500, Glenn Henshaw wrote: > If you have a failing case, I would like a copy of the database to > inspect. yeah sure, thats why I was asking :-) See http://just-imho.net/mantis.test.sql.gz for a dump of the db of my mantis test installation. Basically its the db of an 0.19 installation which has been upgraded automatically with the sql statements produced by upgrade.php. Should have been the extended set that I used for the Debian upgrade path. > The schema definition is incremental (see admin/schema.php). > Developers use create or alter statements as appropriate. I don't know if it is a problem with my current installation, but I get an error if I try to access admin/schema.php: Fatal error: Call to undefined function config_get() in /usr/share/mantis/www/admin/schema.php on line 23 However I use the "Print SQL statements instead of doing the upgrade" function. It should produce whatever is possible to alter an existing database to become conform to the new db version. That is what I expect this function to do (because the name implicits this) and what it did on upgrade.php. In this case it simply does not. > 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). In the meanwhile I understood that. Please see my answer to John (Message-ID: <200...@in...>) for my suggestion. Short: I suggest a two-phased upgrade procedure, and sql-based upgrades again for the future *after* this transition. > 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. Most current documentation should be part of the package, but here is the almost same documentation: http://people.debian.org/~seanius/policy/dbconfig-common.html/ Well, while dbconfig-common might be similar to what the installer does (well not to hard because it is aiming at the same job :-)) it does this in a slightly different way. Its well integrated into debconf, the debian menu based configuration system. Therefore it asks questions if it needs to, always creates a backup before acting, fully handles common problems and can be fully automatic if the user wants so. The good thing about this thing is, that the procedure for the user is the same not only for mantis but for _every_ package that uses dbconfig-common. To me thats important. > admin/install.php is generally unattended. The "go" button shows up Well. The user at leasts needs to a) install a browser or go to a system that has one b) launch the browser and point it to admin/install.php c) click the go button IMHO this is not unattended, because its something that needs to be done interactively. dbconfig-common does not needs to be done interactive usually. Really if you have a Debian Sid system give it a try. Try installing dbconfig-common and configure it, then install mantis. Off course it will ask questions, but you could preseed this question alltogether with every other question asked during a common Debian installation and do the whole installation (including getting mantis up and configured!) without a single finger strike. > 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. A user who uses the distributors package of a software most commonly does not have a second database userid to upgrade. There is a root user and there is an application user. Thats the most common situation, right? > 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. I understand. However usually you don't need to do complex things to upgrade a database ;-) At least it should be the exception. Best Regards, Patrick |
From: Patrick S. <sch...@in...> - 2008-01-21 07:57:51
|
Glenn, On Mon, Jan 14, 2008 at 08:57:49PM +0100, Patrick Schoenfeld wrote: > Hi Glenn, > > On Mon, Jan 14, 2008 at 11:53:31AM -0500, Glenn Henshaw wrote: > > If you have a failing case, I would like a copy of the database to > > inspect. > > yeah sure, thats why I was asking :-) > [...] you wanted to have a look at my problem. Any proceeding here, after seven days? Best Regards, Patrick |
From: Glenn H. <thr...@lo...> - 2008-02-02 01:48:29
|
On 14-Jan-08, at 2:57 PM, Patrick Schoenfeld wrote: > Hi Glenn, > > On Mon, Jan 14, 2008 at 11:53:31AM -0500, Glenn Henshaw wrote: >> If you have a failing case, I would like a copy of the database to >> inspect. > > yeah sure, thats why I was asking :-) > > See http://just-imho.net/mantis.test.sql.gz for a dump of the db of my > mantis test installation. Basically its the db of an 0.19 installation > which has been upgraded automatically with the sql statements produced > by upgrade.php. Should have been the extended set that I used for the > Debian upgrade path. I had a look oat this in conjunction with bug #0008846: database upgrade from 1.0.8 -> 1.1.1 not working. It looks like the upgrade script that I found in your SVN repository (http://svn.debian.org/wsvn/collab-maint/ext-maint/mantis/trunk/debian/sql/upgrade_database.sql.1.0.6-1?op=file&rev=0&sc=0 ) is missing a setup for the mantis_config_table. If you are creating the database from scratch, the table is created and populated, If you upgrade from 0.19,x, it isn't. Could you confrm this? ... Glenn > > >> The schema definition is incremental (see admin/schema.php). >> Developers use create or alter statements as appropriate. > > I don't know if it is a problem with my current installation, but I > get > an error if I try to access admin/schema.php: > > Fatal error: Call to undefined function config_get() in > /usr/share/mantis/www/admin/schema.php on line 23 > > However I use the "Print SQL statements instead of doing the upgrade" > function. It should produce whatever is possible to alter an existing > database to become conform to the new db version. That is what I > expect > this function to do (because the name implicits this) and what it > did on > upgrade.php. In this case it simply does not. > >> 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). > > In the meanwhile I understood that. Please see my answer to John > (Message-ID: <200...@in...>) for my > suggestion. Short: I suggest a two-phased upgrade procedure, and > sql-based upgrades again for the future *after* this transition. > >> 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. > > Most current documentation should be part of the package, but here is > the almost same documentation: > > http://people.debian.org/~seanius/policy/dbconfig-common.html/ > > Well, while dbconfig-common might be similar to what the installer > does > (well not to hard because it is aiming at the same job :-)) it does > this > in a slightly different way. Its well integrated into debconf, the > debian menu based configuration system. Therefore it asks questions if > it needs to, always creates a backup before acting, fully handles > common > problems and can be fully automatic if the user wants so. The good > thing about this thing is, that the procedure for the user is the same > not only for mantis but for _every_ package that uses dbconfig-common. > To me thats important. > >> admin/install.php is generally unattended. The "go" button shows up > > Well. The user at leasts needs to > a) install a browser or go to a system that has one > b) launch the browser and point it to admin/install.php > c) click the go button > > IMHO this is not unattended, because its something that needs to be > done > interactively. dbconfig-common does not needs to be done > interactive usually. > > Really if you have a Debian Sid system give it a try. Try installing > dbconfig-common and configure it, then install mantis. Off course it > will ask questions, but you could preseed this question alltogether > with > every other question asked during a common Debian installation and do > the whole installation (including getting mantis up and configured!) > without a single finger strike. > >> 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. > > A user who uses the distributors package of a software most commonly > does not have a second database userid to upgrade. There is a root > user > and there is an application user. Thats the most common situation, > right? > >> 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. > > I understand. However usually you don't need to do complex things to > upgrade a database ;-) At least it should be the exception. > > Best Regards, > Patrick > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- Glenn Henshaw Logical Outcome Ltd. t: (613) 853-6702 e: thr...@lo... f: (613) 832-2133 w: www.logicaloutcome.ca This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. |
From: Patrick S. <sch...@in...> - 2008-02-02 10:13:15
|
Hi Glenn, On Fri, Feb 01, 2008 at 08:48:17PM -0500, Glenn Henshaw wrote: > I had a look oat this in conjunction with bug #0008846: database > upgrade from 1.0.8 -> 1.1.1 not working. thanks. > > It looks like the upgrade script that I found in your SVN repository > (http://svn.debian.org/wsvn/collab-maint/ext-maint/mantis/trunk/debian/sql/upgrade_database.sql.1.0.6-1?op=file&rev=0&sc=0 > ) is missing a setup for the mantis_config_table. If you are creating > the database from scratch, the table is created and populated, If you > upgrade from 0.19,x, it isn't. Hm. I created the upgrade sql script with the installer/upgrader of mantis 1.0.6 with "Print SQL Queries" and this is what it outputs if your db was 0.19.x before. About mantis_config_table: See the 4th sql statement in the stated sql file. Its adding a mantis_config_table. After that there are some more queries doing something with the table (deleting old indices, etc.) > Could you confrm this? No. Best Regards, Patrick |
From: Glenn H. <thr...@lo...> - 2008-02-02 19:34:40
|
On 2-Feb-08, at 5:13 AM, Patrick Schoenfeld wrote: > Hi Glenn, > > On Fri, Feb 01, 2008 at 08:48:17PM -0500, Glenn Henshaw wrote: >> I had a look oat this in conjunction with bug #0008846: database >> upgrade from 1.0.8 -> 1.1.1 not working. > > thanks. >> >> It looks like the upgrade script that I found in your SVN repository >> (http://svn.debian.org/wsvn/collab-maint/ext-maint/mantis/trunk/debian/sql/upgrade_database.sql.1.0.6-1?op=file&rev=0&sc=0 >> ) is missing a setup for the mantis_config_table. If you are creating >> the database from scratch, the table is created and populated, If you >> upgrade from 0.19,x, it isn't. > > Hm. I created the upgrade sql script with the installer/upgrader of > mantis 1.0.6 with "Print SQL Queries" and this is what it outputs if > your db was 0.19.x before. It doesn't work. We changed the installer to accommodate other databases (MSSQL, Oracle, pgSQL, ...) in 1.0.0rc3. Yo upgrade from 0.19.x to 1.0.0, you need to run the "admin/upgrade.php" script. I don't believe that it outputs SQL statements. From there on, you ned to use the "admin/install.php" script, that will print the appropriate SQL. Somehow, the following MySQL command was missed. "INSERT INTO mantis_config_table ( value, type, access_reqd, config_id, project_id, user_id ) VALUES ('52', 1, 90, 'database_version', 20, 0 );" This confuses both installers as the older debian installs are also missing the upgrade log table. Without either of these two pieces of information we assume that the database is missing and try to re- install it. > > > About mantis_config_table: > See the 4th sql statement in the stated sql file. Its adding a > mantis_config_table. After that there are some more queries doing > something with the table (deleting old indices, etc.) > >> Could you confrm this? > > No. > > Best Regards, > Patrick I've looked at the debian database installer, and it doesn't meet our needs in being able to a) handle other databases, and b) handle changes that require changing of the database content (e.g., category_id change in 1.2.0). I'll look at making another version of the installer that can run unattended to avoid these mistakes in future. ... Glenn -- Glenn Henshaw Logical Outcome Ltd. e: thr...@lo... w: www.logicaloutcome.ca Mantis Developer and User |
From: Gianluca S. <gi...@gm...> - 2008-02-02 22:20:09
|
On Feb 2, 2008 8:34 PM, Glenn Henshaw <thr...@lo...> wrote: > > I'll look at making another version of the installer that can run > unattended to avoid these mistakes in future. > I contributed one when I started working on mantis; it's admin/upgrade_unattended.php but I just checked and it's broken due to some changes that entered config_defaults_inc.php later. It would be nice if you could fix/improve it (it lacked the install part), though I am afraid it will not help on the Debian issue. |