greg-rychlewski
commented
1 year ago I was thinking of a proposal to ecto sql to help with the locks for concurrent migrations. If I could get something like this accepted do you think you'd want to use it for this adapter?
Create a new configuration option called separate_lock_transaction/separate_migration_transaction
- when
trueuses one transaction to lock for concurrent migrations and a different one to perform the migration (this is the current behaviour enforced by ecto sql for all adapters) - when
falseuses the same transaction to lock for concurrent migrations and perform the migration. this could be used by your adapter withbegin exclusive transaction. and in your adapter if someone asks for migration locks without specifying this option as false can give a warning that the lock will be ignored and to set the option to false. right now the default behaviour of your adapter is to ignore the lock so don't want to start raising or anything like that.
warmwaffles
Closes part of https://github.com/elixir-sqlite/ecto_sqlite3/issues/87.
It doesn't seem to me like anything special needs to be done to support DDL transactions for SQLite. The tests were copied from Ecto SQL and seem to pass with no issue.
For the other part of the issue, locking to prevent concurrent migrations, I don't think anything can be done as is. Ecto requires a separate transaction to hold the lock, independent of the transaction used to perform the migration. This is to allow users the ability to lock even if their migration command cannot be run inside of a transaction.
From what I can tell this is not compatible with how locks work in SQLite. It seems the same transaction has to hold the lock and do the writing. There's no mutually exclusive lock that can be held that will allow a subsequent transaction to perform a DDL statement, from what I can see.
I don't think it's completely hopeless. But I just have to figure out a good proposal for Ecto for an option to allow everything to be in one transaction.