Sebastian Hagedorn writes:
I have only now started playing around with Mailman 3.2, because I never managed to get the earlier releases to work, and reading through the documentation I thought that such situations could be handled with Alembic, as described here under "Database Migrations":
<http://mailman.readthedocs.io/en/latest/src/mailman/docs/database.html>
Is that not the case, and if not, in what cases can or should it be used?
No. What is being discussed in the thread is changing the backend RDBMS, behind the SQL schema. Alembic operates in front of the SQL schema, managing the relationship between Python objects and the SQL schema.
As the "Migration" section states, Alembic is used to handle changes in the model (ie, the Python objects), so that they are reflected in the SQL used to access the backend. Users don't need to use it unless they customize the Python objects (ie, patch Mailman themselves). If *we* change the model between versions, Alembic will automatically be invoked to update the SQL, but the user doesn't need to do anything about it.
The potential issues Mark refers to involve differences in the way the different backend implementations handle SQL (this includes issues like default encodings for strings). These should be few because all the supported backends support standard SQL, but we can't guarantee there will be none. Differences in implementation also mean that you can't use the more efficient and compact dump formats that most implementations provide, because they are implementation- dependent. You need to use the textual format that is actually SQL programs that individually create each table, insert each record, create any needed indices, and so on.