能否将Liquibase Changesets迁移至EF InMemory数据库用于测试？

Short answer: Yes, but with significant limitations and extra work — EF InMemory is a database simulator, not a real relational database, so it doesn’t play nicely with Liquibase’s SQL/DDL-focused workflow. Let’s break down your options, constraints, and better alternatives:

Key Constraints to Know First #

EF InMemory doesn’t support most of the features Liquibase relies on:

• No enforcement of foreign keys, unique constraints, or indexes (it ignores these entirely and only uses your EF model’s structure)
• Complex DDL operations (like ALTER TABLE modifying column types, adding columns with default values, or creating stored procedures) will fail
• Liquibase’s raw SQL changesets (especially database-specific syntax) won’t execute, since InMemory doesn’t parse or run SQL natively
• Transaction behavior is simulated, not true ACID-compliant — this might break tests relying on rollback logic

Options to Use Liquibase Changesets with EF InMemory #

If you’re set on sticking with EF InMemory, you have two main paths:

1. Manual Conversion to EF Core Model/Migrations #

You’ll need to translate each Liquibase changeset into EF Core’s model configuration or migrations:

• For schema changes: Map tables/columns to your entity classes, use IEntityTypeConfiguration to define relationships, or generate EF Migrations that mirror Liquibase’s DDL
• For seed data: Replace Liquibase’s insert/loadData with EF’s HasData (model seed data) or populate the database via DbContext.AddRange() in your test setup
• This works for simple changesets, but becomes tedious with large numbers of scripts — you’ll also lose the "single source of truth" that Liquibase provides

2. Custom Changeset Parser (Advanced) #

Build a small utility to parse your Liquibase XML/YAML/JSON changesets and execute equivalent operations via EF Core’s API:

• For example, parse a createTable changeset and use modelBuilder.Entity<...>() to define the table structure
• Parse insert changesets and call context.Set<...>().Add() for each row
• This requires writing custom logic to handle different changeset types, and won’t support complex SQL or DDL — only basic schema and data operations

Better Alternative: Use SQLite In-Memory Instead #

If you want to keep using your existing Liquibase changesets without rewriting them, SQLite In-Memory is a far better fit. It’s a real relational database that runs entirely in memory, supports most SQL syntax, and works seamlessly with Liquibase.

Here’s a quick workflow for tests:

1. Configure EF Core to use SQLite In-Memory:

   var options = new DbContextOptionsBuilder<YourDbContext>()
       .UseSqlite("Data Source=:memory:;Cache=Shared")
       .Options;
   

2. Create your DbContext instance, open the connection (SQLite memory databases are deleted when the connection closes), and run your Liquibase changesets:

   using var context = new YourDbContext(options);
   await context.Database.OpenConnectionAsync();
   
   // Use Liquibase's .NET API to execute your changelog against the SQLite connection
   var liquibase = new Liquibase(...); // Configure with your changelog path and SQLite connection
   await liquibase.UpdateAsync();
   

3. Now your in-memory SQLite database has all your Liquibase-applied schema and data, and you can run tests against it just like EF InMemory — but with full relational database support.

Final Recommendation #

Unless you have a hard requirement to use EF InMemory, go with SQLite In-Memory. It lets you keep your existing Liquibase workflow intact, avoids the pain of converting changesets, and provides more accurate test results (since it behaves like a real database).

内容的提问来源于stack exchange，提问作者Arkady Spiridonov