On a new install of 1.0.8 on Fedora Core 4, (apache 2.2.4, php 5.0.4, MySQL 4.1.11)
I saw the following on the login page:
WARNING: The database structure may be out of date. Please upgrade here before logging in.
First of all why would I need to upgrade a new install?
2nd: When I run the upgrade it stalls at "0.17-jf-8 Drop votes column of mantis_bug_table". On upgrade.php, it just shows this and following upgrades as "Not applied "
when I looked at the table structure, i noticed that there was no votes column in that table. Other upgrades marked as not applied also seemed to have been applied or didn't ever need applying.
I faked out the upgrade process on the 0.17-jf-8 upgrade by actually adding a votes column. The upgrade process successfully dropped the column but stalled on the next "Not Applied". Its not practical for me to do this for all the other 143 "Not Applied"s
Has anyone run into this? Is there a clean and quick way to address this?
WARNING: The database structure may be out of date.
Moderators: Developer, Contributor
Same problem for me
I'm experiencing exactly the same problem. I think there is something wrong in the process of installing this this version on a new server, without having a previous version installed.
I also got into some errors of the SQL sintax in the process of creating the new database: a generic type "XS" was used in the queries. I had to dig into the source code to discover that this is the generic type used by ADODB in place of the mysql type "TEXT". After having discovered this I run the printed queries (with TEXT replaced in place of "XS") and everything seemed to go well.
I didn't look yet at the source code calling the sql queries that are supposed to apply tha patches to the DB but, in my opinion, there is no error management. Each failing query should check the error code and, if the error reason is that the query is already applied (as for the VOTE column...) the query should mark the patch as applied in any case by adding the proper record to the mantis_upgrade_table (see content of the mantis_upgrade_table)
I think there should be some patch. I will look for it.
Best regards,
Luca
I also got into some errors of the SQL sintax in the process of creating the new database: a generic type "XS" was used in the queries. I had to dig into the source code to discover that this is the generic type used by ADODB in place of the mysql type "TEXT". After having discovered this I run the printed queries (with TEXT replaced in place of "XS") and everything seemed to go well.
I didn't look yet at the source code calling the sql queries that are supposed to apply tha patches to the DB but, in my opinion, there is no error management. Each failing query should check the error code and, if the error reason is that the query is already applied (as for the VOTE column...) the query should mark the patch as applied in any case by adding the proper record to the mantis_upgrade_table (see content of the mantis_upgrade_table)
I think there should be some patch. I will look for it.
Best regards,
Luca
Hi,
that is exactly what I did.
The problem is that, after executing install.php (being forced to select "print SQL", substituiting "TEXT" to "XS" in every query and executing the queries directly on the DB, as I wrote in my previous post),
when I go in the login page, Mantis tells me that my db needs to be upgraded... at this point the upgrade process is not able to apply all the patches and stops exactly at the same point written in the ash's post.
I gave a look at the code an it seems that:
1. install.php generates the correct DB structure but doesn't update mantis_upgrade_table (so, for example, the "vote" field is not present in the mantis_bug_table but, as the fix has not been registered in the mantis_upgrade_table, mantis tells us that that fix has not been applied yet. (this is confirmed by php code that generates the administration page with the list of applied patches)
2. upgrade.php (and following) tries to apply a certain number of "patch queries" but the last ones (starting from the "vote" field one) fail if the patch is already present. No error management.
In my opinion both points are to be considered bugs.
As a test I tried a workaround the "vote" field patch in two different ways:
a. (as ash) manually add a dummy vote column in the mantis_bug_table. Now the fix is applied.
b. manually add a record in the mantis_upgrade table. Now the fix is supposed to be applied (also if the vote colum is still there!!!)
This seems to confirm my analysis.
Is there any patch for this?
Best regards,
Luca
that is exactly what I did.
The problem is that, after executing install.php (being forced to select "print SQL", substituiting "TEXT" to "XS" in every query and executing the queries directly on the DB, as I wrote in my previous post),
when I go in the login page, Mantis tells me that my db needs to be upgraded... at this point the upgrade process is not able to apply all the patches and stops exactly at the same point written in the ash's post.
I gave a look at the code an it seems that:
1. install.php generates the correct DB structure but doesn't update mantis_upgrade_table (so, for example, the "vote" field is not present in the mantis_bug_table but, as the fix has not been registered in the mantis_upgrade_table, mantis tells us that that fix has not been applied yet. (this is confirmed by php code that generates the administration page with the list of applied patches)
2. upgrade.php (and following) tries to apply a certain number of "patch queries" but the last ones (starting from the "vote" field one) fail if the patch is already present. No error management.
In my opinion both points are to be considered bugs.
As a test I tried a workaround the "vote" field patch in two different ways:
a. (as ash) manually add a dummy vote column in the mantis_bug_table. Now the fix is applied.
b. manually add a record in the mantis_upgrade table. Now the fix is supposed to be applied (also if the vote colum is still there!!!)
This seems to confirm my analysis.
Is there any patch for this?
Best regards,
Luca
-
michaelaye
- Posts: 2
- Joined: 21 May 2008, 17:20
Re: WARNING: The database structure may be out of date.
Bump! :)
What's the outcome of this discussion? Still have this issue with a vanilla install via package manager on Kubuntu Hardy. (Mantis 1.0.8)
Greetings,
Michael
What's the outcome of this discussion? Still have this issue with a vanilla install via package manager on Kubuntu Hardy. (Mantis 1.0.8)
Greetings,
Michael