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.
