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.
