View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0021678 | mantisbt | upgrade | public | 2016-09-08 09:51 | 2018-03-31 20:03 |
Reporter | TomR | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Summary | 0021678: After upgrade 1.2.19 -> 1.3.1 database structure still out of date. | ||||
Description | After upgrading I still message in login screen. Warning: The database structure may be out of date. Please upgrade here before logging in. How can IO verify that the database upgrade is succesfull? In notice that the record database_version is not being updated in table mantis_config_table ( still shown 194 in stead of 209 ). | ||||
Steps To Reproduce | So what I did was: Write the SQL statements | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
You might get problems when using stored filters
|
|
I have the same issue. Database Creation Suppressed, SQL Queries follow stored_filter_migrate; ; stored_filter_migrate; ; ALTER TABLE mantis_user_table MODIFY COLUMN password VARCHAR(64) NOT NULL DEFAULT ''; ALTER TABLE mantis_user_table MODIFY COLUMN password VARCHAR(64) NOT NULL DEFAULT ''; CREATE TABLE mantis_api_token_table ( ALTER TABLE mantis_api_token_table ADD UNIQUE INDEX idx_user_id_name (user_id, name); ALTER TABLE mantis_user_table ADD INDEX idx_email (email); ALTER TABLE mantis_bug_file_table MODIFY COLUMN content LONGBLOB; ALTER TABLE mantis_project_file_table MODIFY COLUMN content LONGBLOB; ALTER TABLE mantis_user_table MODIFY COLUMN username VARCHAR(191) NOT NULL DEFAULT ''; ALTER TABLE mantis_user_table MODIFY COLUMN realname VARCHAR(191) NOT NULL DEFAULT ''; ALTER TABLE mantis_user_table MODIFY COLUMN email VARCHAR(191) NOT NULL DEFAULT ''; ALTER TABLE mantis_api_token_table MODIFY COLUMN user_id INTEGER UNSIGNED NOT NULL DEFAULT 0; ALTER TABLE mantis_api_token_table MODIFY COLUMN date_created INTEGER UNSIGNED NOT NULL DEFAULT 1; ALTER TABLE mantis_api_token_table MODIFY COLUMN date_used INTEGER UNSIGNED NOT NULL DEFAULT 1; INSERT INTO mantis_config_table ( value, type, access_reqd, config_id, project_id, user_id ) VALUES ('209', 1, 90, 'database_version', 0, 0 ); Your database has not been created yet. Please create the database, then install the tables and data using the information above before proceeding. |
|
I had the same issue. --- install.php.ori 2016-09-11 19:07:57.000000000 +0200
it explains to Mantis that the current user is 1 (administrator) and this is enough to pass this hurdle. |
|
Thanks @grply69, |
|
Reminder sent to: dregad, vboctor install_stored_filter_migrate() uses filter_ensure_valid_filter to migrate filters of older versions. The upgrade process has to migrate all filters, which means filters from all projects and all users. Independant from that, it's a wrong concept at this place to use a function that depends on settings of a user for a project (view_issues_page_columns). Maybe we should tell users not to upgrade to 1.3.x until this is fixed. |
|
Looking at install_stored_filter_migrate(), I wonder if we would be OK upgrading the filter serialization format and renaming of fields, but skipping the following:
We generally should be executing ensure_valid_filter() on filters after loading them from the database, and hence doing this as upgrade time doesn't necessarily add much value. Also the adjustment of the filter seems to be based on context of project/user which will vary at runtime and based on modified access levels, and hence, it should be part of the apply-to-all generic db upgrade. @atrol do you have a repro that you can validate with the above suggested change? |
|
@vboctor I don't have a testing environment where I can reproduce the issue. |
|
There is a hint in forum that could explain some of the issues around stored_filter_migrate
|
|
For the record, i corrected that approach in PR 862 |
|
@cproensa I don't understand what you mean with it. |
|
I mean, the bit about filter_ensure_valid_filter:
|
|
I don't see how the wrong concept is changed. |
|
hmm, ok |
|
|
|
|
|
Happy to let you know that by the tips in this post a workaround could be found for us. After we deleted all the filters referring to disabled users, the upgrade went smooth: |
|
Hi, I tried this SQL command, but it does not seem to work. I get an error saying "#1093 - You can't specify target table 'mantis_filters_table' for update in FROM clause". Is there something I am missing? |
|
This is a limitation of MySQL (I assume you're using that as database backend). |
|
Upgrade is hanging on duplicate key. So when updaing manualy I changed the last line into: INSERT INTO mantis_config_table ( value, type, access_reqd, config_id, project_id, user_id ) VALUES ('209', 1, 90, 'database_version', 0, 0 ) ON DUPLICATE KEY UPDATE value=209; |
|
Hi, This bug has been hanging around for more than half a year without a proper solution. As a result I cannot upgrade several Mantis installations. Since I can replicate the issue I might be able to help, if I am pointed in the right direction. So far the solutions posted seem to indicate that some of the old filters in the database have an issue, but I don't see a real solution that works in all cases. Is it clear for the developers what is really causing the issue? Or is it just a problem to implement it properly in the upgrade script? |
|
There is obviously a conceptual problem in the way how filter conversion is done.
@mbremer could you provide a database export? |
|
No problem to send a database export, but I don't want to upload it in a public area. Is there a way to send it privately? |
|
You could upload it to a storage (Dropbox, Google Drive, Your FTP server, ...) and add a private note with a link to it. |
|
@mbremer, I don't see any error when upgrading your database, see screen shot. |
|
@mbremer, still the same with your latest upload. I don't see any error when upgrading your database. |
|
Hi atrol, not sure what went wrong here. The database dump mantis_jwst_bak.sql should contain a dump with database_version 183. I just double checked this, it has indeed version 183 when I open the sql export file from my posted link. |
|
You mean 194? |
|
No, I see in the dump 183 |
|
Quite strange, seems something went wrong with my first download as there was no mantis_jwst_bak.sql on my system. I confirm there is version 183 in latest file, but I don't see any error when upgrading the database. |
|
Good to hear that you now have a dump with version 183. You've managed to upgrade without any issues, can you tell me which mantis version you are using for the upgrade? |
|
I used a developer version, but I don't expect any difference when using latest 2.4.0. |
|
OK, when I tried it I used the 1.3.x branch. This could explain the difference. What I can do is check if the 2.4.0 release is doing its job when running the upgrade. |
|
I read the documentation and noticed that the latest Mantis installation requires PHP 5.5.x or higher. We are currently running PHP 5.3.x (as part of the Oracle Linux distribution), so I need to request an upgrade before I can try out Mantis 2.4.0 and report back if it works fine. |
|
I've tested the migration using the v2.4.0 release on an Oracle Linux 7 distribution with a proper version of PHP and I can confirm that the complete upgrade works fine! It does all the steps correctly without any errors. :) Just to make it clear for everybody, it was an upgrade from Mantis 1.2.19 (database version 183) to 2.4.0 (database version 209). |
|
@mbremer that's good to hear, thanks for the feedback ! |
|
I tried upgrading from 1.2.19 to 2.4.1 today. In the table mantis_config_table, there is already an entry for the primary key (config_id, project_id, user_id = 'database_version', 0, 0) with the value 183 ! System: |
|
Sorry. |
|