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.
