Repository: bookwyrm-social/bookwyrm

Issue:
UndefinedTable: relation "bookwyrm_userrelationship" does not exist error
**Describe the bug**
I went to go load up the development env today after a little while of not using it and came across this error when I ran the `docker-compose run --rm web python manage.py migrate` cmd to keep up with new migrations:

```
docker-compose run --rm web python manage.py migrate
Creating bookwyrm_web_run ... done
Operations to perform:
  Apply all migrations: admin, auth, bookwyrm, contenttypes, sessions
Running migrations:
  Applying bookwyrm.0006_auto_20200221_1702_squashed_0064_merge_20201101_1913...Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/utils.py", line 86, in _execute
    return self.cursor.execute(sql, params)
psycopg2.errors.UndefinedTable: relation "bookwyrm_userrelationship" does not exist


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/app/manage.py", line 18, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 395, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 328, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 369, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 83, in wrapped
    res = handle_func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/commands/migrate.py", line 231, in handle
    post_migrate_state = executor.migrate(
  File "/usr/local/lib/python3.9/site-packages/django/db/migrations/executor.py", line 117, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "/usr/local/lib/python3.9/site-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "/usr/local/lib/python3.9/site-packages/django/db/migrations/executor.py", line 245, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/usr/local/lib/python3.9/site-packages/django/db/migrations/migration.py", line 124, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "/usr/local/lib/python3.9/site-packages/django/db/migrations/operations/models.py", line 822, in database_forwards
    schema_editor.add_constraint(model, self.constraint)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/schema.py", line 362, in add_constraint
    self.execute(sql)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/schema.py", line 142, in execute
    cursor.execute(sql, params)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/utils.py", line 100, in execute
    return super().execute(sql, params)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/utils.py", line 68, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/utils.py", line 77, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/utils.py", line 86, in _execute
    return self.cursor.execute(sql, params)
  File "/usr/local/lib/python3.9/site-packages/django/db/utils.py", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/utils.py", line 86, in _execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "bookwyrm_userrelationship" does not exist
```

**To Reproduce**
Run the `docker-compose run --rm web python manage.py migrate` command

**Expected behavior**
Migrations should run

**Desktop (please complete the following information):**
 - OS: Mac OS
- Latest git pull

**Additional context**
I saw a commit with the msg "migrations are fucked" and I'm guessing you've experienced part of this problem before. Happy to provide any other context or try anything out here!



Discussion:
dang that squash migrations was supposed to FIX this problem. if you reset the database and start over it should work, but "delete all your data" is, I suppose, not necessarily a great solution. What migration were you on when you tried to run the latest?
I just updated a Bookwyrm instance I initially set up in July, and after a little wrestling with migrations (my database still had `fedireads_` prefixed tables) I decided it'd be easier to just set up a new instance and then manually migrate the little data I had over in the messiest way possible, by manually merging a database dump of the new and the old.

I'm not sure if it was actually easier than figuring out how to make migrations work, but it did work okay in the end. I think if your tables are old enough that they're named `fedireads` then migrations alone won't work, because unless I'm missing something there's no migration to do that rename? Since the migrations are namespaced it might be possible to create such a migration though? I'm fairly familiar with migrations in general, but not Django's migrations specifically.
I got it in my brain to take another run at this and did a trial of migrating from a pre-rename database and found [this Django command](https://odwyer.software/blog/how-to-rename-an-existing-django-application) which seemed to work a charm, with a few tweaks to integrate that command I was able to migrate my database across the rename with the usual `./fr-dev migrate`. I haven't poked around to see if anything is broken, but the site at least loads.

I'm happy to keep poking and look at putting up a PR with what I've got to integrate it into the existing migration flow it that's helpful, but I'm not sure how solved this problem is already!
oh that's interesting, I didn't think about the name change causing issues for migrations because I reset my local database pretty often in development
I just remembered that when I ran this migration on the production database, I ran `docker-compose exec web python manage.py migrate bookwyrm 0006 --fake` to tick the version number correctly before running the subsequent migrations. It was fully up to date on all the migrations prior to the squash when I did that though
So I unfortunately don't remember which migration I was on when I first ran it because I ended up actually deleting the repo and re-cloning since I barely had any data in the test DB and had a feeling that something got a little messed up between migrations. That said, when I went back through the docker set up on a fresh pull of the repo I still saw this same error.

I wonder if even on a clean install a command like `docker-compose exec web python manage.py migrate bookwyrm 0006 --fake` is needed? I'm pretty new to the Django ecosystem, but if it needs to run 1 migration after the next even on a fresh DB then I'm guessing that same strategy would be needed
Hmm, so the database is managed by Docker and isn't stored in the repo, so I don't think deleting and re-cloning your repo by itself will reset the database as long as you cloned it back into the same directory.

Can you run `docker container ls` to see what containers you have currently? If my guess is correct you'll have a db image that was created some time ago.
Oh I didn't realize that about Docker but it makes lots of sense that it works that way. Yep it's a 4 week old DB. So I suppose I could destroy the docker DB and rebuild from there, or we could leverage this set up to try and dig a little deeper into the migration problem

Resolving patch:
diff --git a/bookwyrm/settings.py b/bookwyrm/settings.py
--- a/bookwyrm/settings.py
+++ b/bookwyrm/settings.py
@@ -40,6 +40,7 @@
     'django.contrib.messages',
     'django.contrib.staticfiles',
     'django.contrib.humanize',
+    'django_rename_app',
     'bookwyrm',
     'celery',
 ]


Test patch: