Migrations code generation. #93
Conversation
|
Can the code generation parts be factored into a separate assembly like Microsoft.Data.Migrations.Design? This is an extension of the pay-per-play principle. If you only ever need to execute this code at design-time, it shouldn't be deployed alongside your application at run-time. |
|
|
||
| public virtual bool? IsUnicode { get; set; } | ||
|
|
||
| // TODO: Implement an annotation mechanism and use it to store the ApiPropertyInfo. |
There was a problem hiding this comment.
It may be possible to just use the Name of the property info and not have to refer this here.
There was a problem hiding this comment.
I think in the metadata APIs, we give you a way to get the Type and the property name, but we make a point not to hold on to PropertyInfo objects.
|
Brice, if my understanding is correct the whole ...Migrations assembly includes "design-time" functionality and is not really needed at run-time, so I am don't think it is necessary to separate the code generation parts into a different assembly. But if you can think of a real-world scenario were that would be helpful, I can easily move those parts into a new assembly. |
| [CanBeNull] string dataType = null) | ||
| { | ||
| return BuildColumn( | ||
| typeof(Boolean), |
There was a problem hiding this comment.
The guidelines want us to use C# type keywords in favor of .NET type names.
|
|
This is coming along very well. The best part is: no Visual Basic generator!Added MigrationCodeGenerator abstract class, CSharpMigrationCodeGenerator implementation, and dispatch methods for code generators on MigrationOperation classes. Added Migration abstract class, MigrationBuilder, TableBuilder and ColumnBuilder classes. Updated relational model and migration model as necessary. Made ExpressionExtensions public until we decide what to do with shared utilities and resource strings. Added TypeExtensions and PropertyExtensions to migration utilities. Added DefaultConstraint struct to better incapsulate the DefaultValue/DefaultSql Added a bunch of unit tests.
ghost
merged commit 
|
Not sure if you guys talked about this offline, but regarding the idea of a design-time assembly, to me the point is that some parts of Migrations can be considered more design-time-ish than others, e.g. while the ability to execute a migration is something that can be done at runtime by any application and shouldn't require extra dependencies to do it programmatically, the code generation part is something that is typically only done while in de IDE. Is this reason enough to create a separate assembly? I don't know but seems worth considering. |
|
I will move the code generation class into a separate assembly as Brice suggested. However, it may be better to move the migration operations into the Relational assembly in which case there won't be a need to create this extra assembly with one class. Those operations are practically database operations, not really migration operations. |
- Remove remaining DbDataReader dependencies from query processing - Use ValueBuffer everywhere. - Removed offsetting from ValueBuffer factory factories. - Enables dynamic ValueBuffer index re-mapping for FromSql non-composed projection out-of-order scenarios. - Adds workaround for IX-Async #93 - Enables Select op over non-composed FromSql queries! dprun: 100%
- Remove remaining DbDataReader dependencies from query processing - Use ValueBuffer everywhere. - Removed offsetting from ValueBuffer factory factories. - Enables dynamic ValueBuffer index re-mapping for FromSql non-composed projection out-of-order scenarios. - Adds workaround for IX-Async #93 - Enables Select op over non-composed FromSql queries! dprun: 100%
- Remove remaining DbDataReader dependencies from query processing - Use ValueBuffer everywhere. - Removed offsetting from ValueBuffer factory factories. - Enables dynamic ValueBuffer index re-mapping for FromSql non-composed projection out-of-order scenarios. - Adds workaround for IX-Async #93 - Enables Select op over non-composed FromSql queries! dprun: 100%
Added MigrationCodeGenerator abstract class, CSharpMigrationCodeGenerator implementation, and dispatch methods for code generators on MigrationOperation classes.
Added Migration abstract class, MigrationBuilder, TableBuilder and ColumnBuilder classes.
Updated relational model and migration model as necessary.
Made ExpressionExtensions public until we decide what to do with shared utilities and resource strings.
Added TypeExtensions and PropertyExtensions to migration utilities.
Added DefaultConstraint struct to better incapsulate the DefaultValue/DefaultSql
Added a bunch of unit tests.