squidex

Headless CMS and Content Managment Hub

csharp asp-net asp-net-core cms headless-cms mongodb

Joe 8a4cae16dd fix: move JSON function creation into EF Core migrations to prevent startup failure on restart (#1313 ) * fix: use CREATE OR ALTER/REPLACE FUNCTION to prevent startup failure on restart On application restart the hosted service fails with: SqlException: There is already an object named 'json_exists' in the database. The #if RELEASE guard in JsonFunction.cs skips DROP FUNCTION IF EXISTS statements in release builds, so CREATE FUNCTION fails if the functions already exist from a previous run. Replace the DROP + CREATE pattern with idempotent alternatives: - SQL Server: CREATE OR ALTER FUNCTION (supported since SQL Server 2016 SP1) - MySQL: CREATE OR REPLACE FUNCTION PostgreSQL was already using CREATE OR REPLACE FUNCTION correctly. DROP FUNCTION IF EXISTS statements are removed from both SQL files. * Move JSON function creation into EF Core migrations - Replace SqlDialectInitializer startup logic with proper EF Core migrations for all three providers (MySQL, SQL Server, Postgres) - SQL Server: uses CREATE OR ALTER FUNCTION (idempotent, no DROP needed) - MySQL: uses DROP FUNCTION IF EXISTS + CREATE FUNCTION in migration - Remove SqlDialectInitializer registration from production ServiceExtensions - Add migration tests: idempotency and upgrade-from-pre-migration-database * Add Postgres migration tests; fix image tag for arm64 compatibility * Replace DatabaseCreator+SqlDialectInitializer with DatabaseMigrator in test fixtures - Test fixtures now use the same code path as production (MigrateAsync) - DatabaseCreator and SqlDialectInitializer are no longer needed and deleted - Functions are created via the AddJsonFunctions migration, not at every startup * Fix missing Squidex.Infrastructure using in test fixtures * Fix test fixtures: use EnsureCreated+Dialect.InitializeAsync and per-prefix migration history Two bugs fixed in the EF Core test fixtures (PostgresFixture, MySqlFixture, SqlServerFixture): 1. Replace DatabaseMigrator with EnsureCreatedAsync + Dialect.InitializeAsync TestDbContext* are test-only contexts with no EF migration files, so DatabaseMigrator<TestDbContext>.InitializeAsync called MigrateAsync which was a complete no-op — no tables were ever created and all integration tests failed with 'relation does not exist'. EnsureCreatedAsync builds the schema directly from the EF Core model, which is the correct approach for contexts without migrations. Dialect.InitializeAsync is then called explicitly to create the database-specific JSON functions (json_exists etc.) that EnsureCreated does not set up. 2. Add per-prefix MigrationsHistoryTable for named ContentDbContext registrations DynamicTables.PrepareAsync calls MigrateAsync on the named ContentDbContext (e.g. PostgresContentDbContext) to create per-app/schema dedicated tables such as '__c5_ContentsAll'. The migration (AddInitial) reads TableName.Prefix to build the table name at runtime. All named contexts shared the default '__EFMigrationsHistory' table, so after the first prefix ran AddInitial and recorded it, every subsequent prefix saw the migration as already applied and skipped it — leaving its dedicated tables uncreated and causing 'relation __cN_ContentsAll does not exist' failures in all but the first dedicated-table test. Setting options.MigrationsHistoryTable(\$"{name}MigrationHistory") gives each prefix its own independent migration history, so AddInitial runs once per prefix and creates the correct tables each time. Also add .lscache to .gitignore (C# language server cache files).		2 days ago
..
Domain	User info (#1278)	4 months ago
Infrastructure	Improve queries (#1293)	3 months ago
Migrations	fix: move JSON function creation into EF Core migrations to prevent startup failure on restart (#1313)	2 days ago
TestHelpers	fix: move JSON function creation into EF Core migrations to prevent startup failure on restart (#1313)	2 days ago