I think you're right about using the base class rather than an interface. However I don't see how I can get away from version properties. The nature of migrations in general and this framework in particular is to keep the schema synchronized with the version of the application that's deployed. Applying alter or drop statements at the incorrect point is potentially disastrous. The core concept here is that a Migration encapsulates the set of operations which transform the database from one version to another.
As for the DB specific bits... My fork has a new abstraction layer around Data Definition Language generation. Each logical operation like "Create Table <https://github.com/jeffreyabecker/nhibernate-core/blob/migrations/src/NHibernate/DdlGen/Operations/CreateTableDdlOperation.cs>" is encapsulated in an IDdlOperation <https://github.com/jeffreyabecker/nhibernate-core/blob/migrations/src/NHibernate/DdlGen/Operations/IOperation.cs> class and receives all its information via a model. That class is responsible for looking at the Dialect and producing appropriate SQL statements. Dialect encapsulates all the differences from standard SQL for a given dialect. Right now, I've only implemented operations to support the existing DDL generation systems. Up to this point the modifications needed to dialect have been minimal. If Dialect doesn't have the properties or methods needed to generate DDL in a database independent manner we should add them. Entity Framework ships operations which offer much more functionality than its ddl generator, such as operations for creating procedures, altering primary keys and renaming tables. Maybe we should consider something similar? On Saturday, September 6, 2014 11:20:36 AM UTC-4, Ricardo Peres wrote: > > Hi, Jeff! > > Since you asked, here are some random thoughts! :-) > Why did you choose to represent migrations as interfaces? IMO, a migration > is a migration is a migration, not somehing else, so I'd use a class, like > EF. Using an interface allows dreadful things, such as having > entity-migrations and the likes. > I wouldn't also go for version properties; this gives the idea that a > migration only targets a specific source-destination version pair. I would > prefer a method with context, from which you could extract the source and > destination versions, the driver and dialect in use, etc, and where you > could store the modifications. > As for the fluent interface, I think you can leave it for later, first try > to have a stable class model. > How about having some provider model for DB-specific operations (create > table, view, index, etc)? NHibernate's driver and dialect classes don't > offer much. > > Keep on sharing your progresses! > > Cheers, > > 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.
