You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Generally speaking, concurrent invocations of Migrate() will fail and possibly leave the database in a corrupted state. In order to mitigate this, we could create a temporary table using HistoryRepository that will serve as a lock while the migrations are applied by the process that acquired it. Providers will be able to override all related logic to instead leverage database-specific mechanisms to accomplish this.
The text was updated successfully, but these errors were encountered:
That's a good idea - databases do frequently expose locking mechanisms that could work well, e.g. full-table exclusive lock on the HistoryRepository table for PG and SQL Server. Though I'm not sure what a default implementation would look like here - what do you have in mind with the temporary table?
what do you have in mind with the temporary table?
Before applying migrations create __EFLock table. If it was created successfully - the lock was acquired. If not, enter the normal retry loop.
After migrations and seeding (#17568) finished applying delete __EFLock table.
Generally speaking, concurrent invocations of
Migrate()
will fail and possibly leave the database in a corrupted state. In order to mitigate this, we could create a temporary table usingHistoryRepository
that will serve as a lock while the migrations are applied by the process that acquired it. Providers will be able to override all related logic to instead leverage database-specific mechanisms to accomplish this.The text was updated successfully, but these errors were encountered: