Honestly, I think its way less pollution of Dialect than you'd imagine. Indexes, Foreign Keys & Sequences are all already in Dialect with corresponding IDdlOperations and my research indicates that Views wouldn't need any dialect support at this time. In terms of stored procedures, I'm not sure if baking in support would be a good idea. Yes EF has baked in support but I don't know anyone who uses it. I'm fine with saying "if you want procs, use raw ddl". In terms of EF Migrations, they're not supported by many third-parties because they're a change/addition to the provider which requires a reference to EF6 which breaks older apps. More-over the EF way requires an large duplication of code both between and inside providers.
In terms of versions... Yes they're for determining which migrations to execute. They wouldn't work particularly well as attributes because they have a Configuration (probably serialized) stored in them for migration generation. I'm not particularly concerned about instantiating instances of migrations for several reasons. First the instances generated by the tooling will be fairly light-weight. I expect that most people will just use these out of the box with little in the way of customization; it would be unusual to write one from scratch. Second, I'm probably going to need at least some of the instances anyway. On Monday, September 8, 2014 3:27:49 AM UTC-4, Ricardo Peres wrote: > > For the DB, I saw your pull requests for add/drop, etc, but there's much > more to it. EF didn't really solved the problem, since, AFAIK, migrations > only work for SQL Server. If you don't want to fallback to SQL, you'd need > primitives for procedures, views, indexes, etc, all to go in the Dialect... > A lot of "pollution" which will only be required for migrations. > Regarding versions, I understand that a migration may only be apropriate > for changing the schema, say, from version 1 to version 2, right? Even so, > why are the version properties required? Are they for the framework to > query the source and destination versions, from a migration instance that > is instantiated dynamically? If that is the case, you might as well go with > attributes, these are static, meaning, you don't need an instance to query > them, so you can find the proper migration dynamically from an assembly > without actually creating instances. > These are my 5 cents! :-) > > RP > -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
