New migrations failing on startup #96
Comments
|
I think we can save your database. What we're really trying to save is the read/unread & bookmarks information. Everything else can be recreated from an empty database.
1. I recommend updating to the latest version of Codex. v0.7.0 did
experience an integrity check error for some databases (sadly, not my test databases). v0.7.3 has fixes
for I think the particular error you experienced. This will likely solve your issue.
2. But... if you still experience a crash like this, with the latest Codex, please post another trace for
me to look at and then try starting Codex with the
`CODEX_SKIP_INTEGRITY_CHECK=1` environment variable set.
…On Sat, Dec 18, 2021 at 1:35 PM Chris Rees ***@***.***> wrote:
It looks like my Codex server has been down for a few days, likely around
the time the new version was released. I checked the logs and found this:
2021-12-18 16:32:11 EST INFO Loaded config from /config/hypercorn.toml
2021-12-18 16:32:12 EST WARNING no such table: codex_comic_folders
No changes detected in app 'codex'
Operations to perform:
Apply all migrations: admin, auth, codex, contenttypes, sessions
Running migrations:
Traceback (most recent call last):
File "/usr/local/bin/codex", line 8, in <module>
sys.exit(main())
File "/usr/local/lib/python3.10/site-packages/codex/run.py", line 67, in main
update_db()
File "/usr/local/lib/python3.10/site-packages/codex/run.py", line 34, in update_db
call_command("migrate")
File "/usr/local/lib/python3.10/site-packages/django/core/management/__init__.py", line 187, in call_command
return command.execute(*args, **defaults)
File "/usr/local/lib/python3.10/site-packages/django/core/management/base.py", line 417, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.10/site-packages/django/core/management/base.py", line 90, in wrapped
res = handle_func(*args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/django/core/management/commands/migrate.py", line 253, in handle
post_migrate_state = executor.migrate(
File "/usr/local/lib/python3.10/site-packages/django/db/migrations/executor.py", line 126, in migrate
state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.10/site-packages/django/db/migrations/executor.py", line 156, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.10/site-packages/django/db/migrations/executor.py", line 235, in apply_migration
with self.connection.schema_editor(atomic=migration.atomic) as schema_editor:
File "/usr/local/lib/python3.10/site-packages/django/db/backends/sqlite3/schema.py", line 35, in __exit__
self.connection.check_constraints()
File "/usr/local/lib/python3.10/site-packages/django/db/backends/sqlite3/base.py", line 346, in check_constraints
raise IntegrityError(
django.db.utils.IntegrityError: The row in table 'codex_comic_characters' with primary key '15653' has an invalid foreign key: codex_comic_characters.comic_id contains a value '1674' that does not have a corresponding value in codex_comic.id.
Applying codex.0006_update_default_names_and_remove_duplicate_comics...%
Is the best option here to just blow away my database and rebuild it? I
had put in a lot of manual work to get some issues to be recognized
properly and would not like to do that again, but I could. I also think
that was just fixing the metadata of the issues themselves, so I suspect
they'd import properly this time.
—
Reply to this email directly, view it on GitHub
<#96>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACAKRRTYLIGUIE6Z4W4Z33URT5DNANCNFSM5KLDD6AQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I did a I also tried with the |
|
Please try Codex 0.7.4. I only have a limited number of corrupt databases to test with so if this version doesn't fix your issue, consider sending me your database itself to aj@slater.net so I may be assured of fixing your issues in the next release. If you don't feel like doing another log trace will also help. As a practical matter to get up and running more quickly, if v0.7.4 doesn't do the trick you might also try the emergency database repair procedure documented in the Troubleshooting section of the README. |
|
Here's my log with 0.7.4. I'll see what I can do about getting you a copy of my database |
|
Just for good measure, I also tried the database rebuild: |
|
A fix is currently making its way through ci: |
|
Release v0.7.5, now on docker hub and elsewhere, contains a fix for the specific issue you ran into. Give it a whirl. You will have to run the integrity checker normally for the migrations to succeed. |
|
That looks like it did it. Thanks for all of your help |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It looks like my Codex server has been down for a few days, likely around the time the new version was released. I checked the logs and found this:
Is the best option here to just blow away my database and rebuild it? I had put in a lot of manual work to get some issues to be recognized properly and would not like to do that again, but I could. I also think that was just fixing the metadata of the issues themselves, so I suspect they'd import properly this time.
The text was updated successfully, but these errors were encountered: