This was attempted in #187, but the schema generated was too different to the existing one on the production DB (difference checked using pgAdmin).
The advantages of doing this are:
- to remove old stuff
- totally dump the sqlalchemy_utils package as a dependancy (it is needed for decryption stuff)
- generate migrations with type stubs
- generate migrations that use the async dbapi (doesn't actually gain us much for migrations purposes)
- fix the slightly broken schema
The current best solution we can come up with is to write a script that connects to both the old and a new database and copies the tables over a row at a time.
This was attempted in #187, but the schema generated was too different to the existing one on the production DB (difference checked using pgAdmin).
The advantages of doing this are:
The current best solution we can come up with is to write a script that connects to both the old and a new database and copies the tables over a row at a time.