The primary goal is to make a framework which supports coded migrations between versions of a Mapping, independent of the underlying database & schema. The framework should have the following major features:
- Unified DDL generation across NHibernate / DDL from schema export should match the DDL from Migrations for trivial cases - Be flexible enough that consumers can encapsulate dialect specific operations in a testable fashion - A Domain specific language / fluent API for coded migrations - A Code generator which creates Migration classes based on such an api - A migration execution framework which compares Mappings in the DB to Current and selects a set of migrations to execute at run-time. Some background: In the past I've worked on a product where we used NHibernate while supporting several different databases in the product. The data migrations were one of the hairiest parts of the application. SchemaUpdate was virtually useless because some changes required dropping and rebuilding tables which it messed up badly. Versioning was inconsistent at best; Mostly the current version was kept in a table except for version 3.12 where it was in an extended property on SqlServer, in a table comment on Oracle, and in the table for the rest. The migrations themselves quickly became a rats-nest of bad, conditional DDL building. On Friday, August 22, 2014 1:54:47 PM UTC-4, Ricardo Peres wrote: > > And do you have something that describes your "vision", what functionality > you'd like to have, so that we can discuss them? > > RP > > On Friday, August 22, 2014 6:34:12 PM UTC+1, Jeffrey Becker wrote: >> >> I've just been slammed recently. >> >> The repo is up on my github at >> https://github.com/jeffreyabecker/nhibernate-core. The commits are a bit >> of a stream-of-consciousness mess at the moment. >> >> The core ddl generation rewrite into the DdlOperation framework is in >> there. Currently I've been playing around with encapsulating that stuff >> into a Migration class but I'm not sure I'm happy about how that's going. >> >> On Friday, August 22, 2014 9:55:02 AM UTC-4, Ricardo Peres wrote: >>> >>> Hi, Jeffrey! >>> >>> Need help with this? Do you have a public repository? >>> >>> RP >>> >>> On Sunday, August 3, 2014 5:00:28 PM UTC+1, Jeffrey Becker wrote: >>>> >>>> I'm almost done my infrastructure work & unit tests on the DDL >>>> generation portion of NHibernate needed to support my proposed migrations >>>> feature. As of now I've got an interface: >>>> >>>> public interface IDdlOperation >>>> { >>>> IEnumerable<string> GetStatements(NHibernate.Dialect.Dialect >>>> dialect); >>>> } >>>> >>>> I've re-implemented the ddl generation in the Mapping namespace as a >>>> series of implementations of this interface. Each of these classes >>>> accepts >>>> a model which contains the relevant information for building the sql >>>> statements. As much as possible database object names are passed to these >>>> classes pre-qualified and pre-quoted. The relevant mapping classes have >>>> been changed from implementing IRelationalModel to having methods that >>>> produce one or more relevant IDdlOperation instances. The Configuration >>>> class was updated to use these methods. >>>> >>>> >>>> While I finish out the unit tests and get it all staged into a coherent >>>> set of commits for a pull request I'd like some feedback on the following >>>> topics: >>>> >>>> Currently the Configuration/Mapping classes quote and qualify objects >>>> using the dialect methods which results in dialect specific quoting. I >>>> this does not present a problem in the existing system because analysis >>>> always happens at the same time as execution and the target dialect is >>>> known. In a world with coded migrations a migration could be generated >>>> against a one dialect and executed against another with incompatible >>>> quoting. Should these methods be changed to quote and qualify using >>>> back-tick quoting and the operations be changed to mangle those quotes >>>> into >>>> dialect specific quoting? >>>> >>>> Where is the dividing line between NHibernate and non-core Migrations >>>> features if any? I see this framework eventually containing components >>>> such >>>> as versioning strategies, a fluent migration building DSL, a migration >>>> execution framework, and a component which generates/executes coded >>>> migrations within the package manager console. At a minimum that 3rd >>>> piece >>>> needs to be a separate assembly because of its dependency on visual >>>> studio. >>>> How to people feel about the rest? Should I aim to include some / all of >>>> that within Nhibernate or split it out into a separate assembly? >>>> >>>> How do people feel about a fluent DSL for building the coded >>>> migrations? How do we make this into something which is both expressive >>>> enough for people to write a migration themselves and flexible enough that >>>> they don't have to resort to issuing raw sql for everything? >>>> >>>> -- --- 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 nhibernate-development+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
