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.
