Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Database migrations issue during upgrade from 2.1.5 to 2.2.0 #2795
Please provide issue details here.
Steps to reproduce/test case
After upgrading from 2.1.5 to 2.2.0 using
At first I was just sent back to the login page and I tried to reset my password, but there was this error :
Then, I ran
Now when I try to log in, I have this error :
Obviously some migrations have not been properly applied on my database.
Here the output of
The missing column is defined in the version
For now Wallabag seems fine, I can login, read some articles, share them or save new ones with Wallabagger.
But that doesn't tells us why Doctrine didn't applied this migration even though it did say so.
Not sure if the same thing but:
Migrating up to 20170127093841 from 0
++ migrating 20160410190541
Migration 20160410190541 failed during Execution. Error An exception occurred while executing 'INSERT INTO wallabag_craue_config_setting (name, value, section) VALUES ('share_public', '1', 'entry')':
SQLSTATE: Integrity constraint violation: 19 UNIQUE constraint failed: wallabag_craue_config_setting.name
I got the two same two problems too, but given the (different) error I had ( #2797 ) I've supposed these errors was my fault
edit: To get rid of the unique constraint problem, I had to manually migrate all versions individually, as explained here
Maybe this is similar:
I have a setup with nginx, PHP7-FPM and PostgreSQL on openSUSE Leap 42.2 and use the tar archives for shared hosting because I prefer extracting tar archives over dealing with that composer stuff. So I had to do these migrations by hand and now I get
after login. Some of those SQL statements of the migrations returned errors, like
I also had an error at 20161022134138 step
ALTER DATABASE wallabag CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
...query didn't worked.
I replaced MySQL with MariaDB a few years ago, maybe an incompatibility ?
To bypass this issue I reduced the length of columns from 255 to 155 (shorter), ran the query on each table instead of full database. Then increased them to 255 again. Hope it is equivalent...
Then I ran other queries of this update step :
ALTER TABLE wallabag_user CHANGE confirmation_token confirmation_token VARCHAR(180) DEFAULT NULL;
Then I ran other updates from the command line :
bin/console doctrine:migrations:execute 20161024212538 --env=prod
Wallabag seems to work well now.
@benediktg I think you forgot or had an issue with 20161214094402 step
ALTER TABLE wallabag_entry CHANGE uuid uid VARCHAR(23)
@nicosomb do you think I could have issues in the future since I did 20161022134138 step manually ?
Should I add 20161022134138 in 'migration_versions' ?
referenced this issue
Jan 29, 2017
my wallabag just broke, too, with the upgrade from 2.1.5 to 2.2. Second run of
Which I could resolve by re-applying the db migration which introduced
seems to work fine now.
I have PostgreSQL and there is no
ALTER TABLE wallabag_entry RENAME COLUMN uuid TO uid;
instead seemed to do the job. ;)
@FrenchHope > Should I add 20161022134138 in 'migration_versions' ?
Yes, you should.
For all, I also noticed that the migration command told that all is fine but some migrations are not well played (like for http_status column).
I fixed this error (ping @Alwaysin):
I added hardcoded query for
I open a new Work in progress pull request for these fixes.
referenced this issue
Jan 30, 2017
I just wrote a fix (it's a draft) for SQLite migrations: https://gist.github.com/nicosomb/7c537995f2b845a30b4d6cdf23c1e22c
Hmm, not working for me - now I'm seeing this even when i recover Wallabag from backup:
500: Internal Server Error
An exception has been thrown during the rendering of a template ("An exception occurred while executing 'SELECT COUNT(*) AS dctrn_count FROM (SELECT DISTINCT id_0 FROM (SELECT w0_.id AS id_0, w0_.uuid AS uuid_1, w0_.title AS title_2, w0_.url AS url_3, w0_.is_archived AS is_archived_4, w0_.is_starred AS is_starred_5, w0_.content AS content_6, w0_.created_at AS created_at_7, w0_.updated_at AS updated_at_8, w0_.mimetype AS mimetype_9, w0_.language AS language_10, w0_.reading_time AS reading_time_11, w0_.domain_name AS domain_name_12, w0_.preview_picture AS preview_picture_13, w0_.is_public AS is_public_14 FROM
I have the same issue here (from 2.1.1)
But unfortunately, I get an error at the first command:
then I tried
You are right, some directories were owned by www-data user instead of me.
I was able to successfully apply your fix:
Now I have a Wallabag 2.2.1 up and running :)
Thank you for your help and your work on Wallabag!! :)
Wondering: I just got to upgrade fro 2.1.6 to 2.2.1 by following the documentation (
I see this issue was closed. Did the fix make it in a version later than 2.2.1? Because for me 2.2.1 is still broken coming from 2.1.6 and thus this issue shouldn't be closed until it is fixed or the workaround is documented in the upgrade documentation.
Manually applying the steps from https://gist.github.com/nicosomb/7c537995f2b845a30b4d6cdf23c1e22c worked (the only migration not skipped while applying was 20161118134328).
But as said, unless this "just works" while updating according to the documentation (in my case from 2.1.6 to 2.2.1 didn't work as expected) or the documentation being updated for any manual step, I suggest reopening this issue.