FluentMigrator v2

gistfile1.md

FluentMigrator V2

Main goals

• Extensibility
• Conventionalize
• Improve reusability

Concepts

Fluent API

• Expressions should have base classes (TableExpression, ColumnExpression)
• All builders should expose underlying expressions so they can be altered in any way
• Expressions should allow conventions like for instance (table => DefaultSchemaConvention, column => DefaultNullableConvention)

Processors

• Separate the processing from the generation part, allready have it in someway
• Introduce Dialects for instance Generators use a Dialect like Sql2000, Sql2005, ...
• You select processor by choosing dialect, except for fileprocessor where you should still specify dialect
• All Generators only generate necessary sql statements
• Processors can only execute statements
• Use a composition engine like for instance mef, so the system can be extended
• Separate all DB specific stuff into different assemblies for instance (FluentMigrator.SqlServer) this would allow multiple communities to work on different db's
• A generator handles (think of iHANDLE<Expression) expressions but none will be enforced, the framework will check if the generator implements the interface, otherwise notsupportedexception

Start with following db's and define clear leads for it

• SqlServer (which will be same team as core team)
• Postgres (which will be same team as core team)
• Oracle(if we find the community for it ;))
• MySql (maybe see oracle)