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
Part of the EF Core migration generation epic — tracking issue #371.
The core translation layer: walk Weasel's strongly-typed schema model and produce EF Core MigrationOperation-shaped output, the reverse of the existing MapToTable (EF → Weasel) direction in Weasel.EntityFrameworkCore/DbContextExtensions.cs.
Design
Lives in Weasel.EntityFrameworkCore (already references Microsoft.EntityFrameworkCore.Relational + Weasel.Core, no concrete provider).
Input is the provider-neutral surface (ITable, ITableColumn, ITableIndex, ForeignKeyBase) with provider-specific strategy hooks that downcast to the concrete Table types — the same pattern the SchemaComparison harness uses via customizeTables.
Output is an intermediate operation list that the file emitter (separate issue) renders as MigrationBuilder calls. Use raw store type strings (ColumnType) everywhere so EF's CLR type mapping is bypassed and DDL matches Weasel exactly.
PL/pgSQL functions, SQL Server stored procedures and table types
Sequences with DefaultValueFromSequence / nextval expressions
Rich PG index options (gin/gist methods, CONCURRENTLY → suppressTransaction: true, tablespaces, fill factor, collation, nulls-not-distinct)
Acceptance
For every SchemaComparison scenario table, the translated operations describe the same schema Weasel's own DDL produces (validated end-to-end by the harness-inversion issue).
Deliberate design note: because Weasel authors the operations, renames emit RenameColumnOperation/RenameTableOperation instead of EF's drop+add.
Part of the EF Core migration generation epic — tracking issue #371.
The core translation layer: walk Weasel's strongly-typed schema model and produce EF Core
MigrationOperation-shaped output, the reverse of the existingMapToTable(EF → Weasel) direction inWeasel.EntityFrameworkCore/DbContextExtensions.cs.Design
Weasel.EntityFrameworkCore(already referencesMicrosoft.EntityFrameworkCore.Relational+Weasel.Core, no concrete provider).ITable,ITableColumn,ITableIndex,ForeignKeyBase) with provider-specific strategy hooks that downcast to the concreteTabletypes — the same pattern theSchemaComparisonharness uses viacustomizeTables.MigrationBuildercalls. Use raw store type strings (ColumnType) everywhere so EF's CLR type mapping is bypassed and DDL matches Weasel exactly.Mapping table
Table+ PKCreateTable(nested columns,PrimaryKey, checks)TableColumn(Type,AllowNulls,DefaultExpression)AddColumnOperationw/ColumnType,IsNullable,DefaultValueSqlIsAutoNumberNpgsql:ValueGenerationStrategyidentity,SqlServer:Identity)ComputedColumnSqlIndexDefinition(unique, predicate, INCLUDE)CreateIndexOperation(+ provider annotations for filter/includes)ForeignKey(DeleteAction/UpdateAction)AddForeignKeyOperationw/ReferentialAction(mirrormapDeleteBehaviornormalization, e.g. SQL Server Restrict ≡ NoAction)EnsureSchemaOperationPreserveIdentifierCaseRaw-SQL fallback strategy
Everything EF cannot model routes through
Sql()using the existingWriteCreateStatement/WriteDropStatementoutput, so these work on day one:DefaultValueFromSequence/nextvalexpressionsCONCURRENTLY→suppressTransaction: true, tablespaces, fill factor, collation, nulls-not-distinct)Acceptance
SchemaComparisonscenario table, the translated operations describe the same schema Weasel's own DDL produces (validated end-to-end by the harness-inversion issue).RenameColumnOperation/RenameTableOperationinstead of EF's drop+add.