Sync to EF Core 9.0.0-rc.2.24460.3 #3275
Conversation
| /// doing so can result in application failures when updating to a new Entity Framework Core release. | ||
| /// </summary> | ||
| public override IDisposable GetDatabaseLock() | ||
| public override IMigrationsDatabaseLock AcquireDatabaseLock() |
There was a problem hiding this comment.
@AndriySvyryd here's the PG implementation of the final implementation of the migration lock... Everything seems OK (at least the MigrationsInfrastructureTestBase.Can_apply_*_in_parallel are passing).
Note that NpgsqlMigrationDatabaseLock is a no-op, as it generally will always be when LockReleaseBehavior is Transaction (since the lock is implicitly released when the transaction terminates, and not before). So it effectively functions only as a wrapper for MigrationHistory - feels a bit weird, but fine.
| GetCreateIfNotExistsCommands(), Dependencies.Connection, new MigrationExecutionState(), commitTransaction: true) | ||
| != 0; | ||
| } | ||
| catch (PostgresException e) when (e.SqlState == "23505") |
There was a problem hiding this comment.
@AndriySvyryd note this annoying thing to deal with the PG problem of doing CREATE TABLE IF NOT EXISTS in parallel :/
There was a problem hiding this comment.
It's only a real issue when running test code that exercises these convoluted scenarios. I'd say that the correct thing here is to let it throw and handle it in the execution strategy used in tests
| { | ||
| var script = GetCreateScript(); | ||
| return script.Insert(script.IndexOf("CREATE TABLE", StringComparison.Ordinal) + 12, " IF NOT EXISTS"); | ||
| return script.Replace("CREATE TABLE", "CREATE TABLE IF NOT EXISTS"); |
There was a problem hiding this comment.
Nothing like some string-based code reuse 😆
Closes #3223