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.
