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.
