CockroachDB translator generates SQL which can/will break databases #104
Comments
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment. Otherwise, this will be closed in 7 days. |
|
This issue was closed because it has been stalled for 30+7 days with no activity. |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment. Otherwise, this will be closed in 7 days. |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment. Otherwise, this will be closed in 7 days. |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment. Otherwise, this will be closed in 7 days. |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment. Otherwise, this will be closed in 7 days. |
|
This issue was closed because it has been stalled for 30+7 days with no activity. |
Currently, the CockroachDB translator generates statements that are executed in transactional isolation by appending
COMMIT TRANSACTION;BEGIN TRANSACTION;introduced by this commit: da6a949The idea behind this is simple. CRDB does not support mixing SCHEMA DDL and non-DDL in a single transaction. The idea of the approach is to run each statement in its own transaction.
The problem is though, if any of the transaction fails, the rollback mechanism will not work. Leaving the database in a state where parts of the transactions have completed while others have not. The way the pop migrator works (keeping track of which files have been applied) means that we can end up in a state where migrations can no longer be applied and manual intervention is required.
We will probably work around this ourselves using the approach I outlined in #92 and splitting every SQL instruction into its own file, to ensure that we never end up with a broken state.
The text was updated successfully, but these errors were encountered: