1) A DML/DDL split is not going to happen. Too broad.
2) keep this discussion on list please.
On Wed, 2009-06-10 at 14:49 +0200, Francis Galiegue wrote:
> 2009/6/10 Steve Ebersole <st...@hibernate.org>:
> > On Tue, 2009-06-09 at 17:11 +0200, Francis Galiegue wrote:
> [...]
> >>
> >> Steven has pointed to a Jira task talking about an overhaul of the
> >> Dialect abstract class and all its derivatives, because for one, the
> >> Dialect doesn't provide "purpose oriented" capabilities, just one big
> >> lump of methods. After looking at the code (3.3.1), I can see that
> >> this is the case: for instance, there's no separation between DML and
> >> DDL.
> > Well the JIRA[1] to which I pointed you does not really go into this
> > per-se. It is more talking about potentially changing the way DDL is
> > created to use a delegate. Currently what happens is that the mapping
> > objects (Table, Index, etc) all know how to create DDL there own DDL.
> > The tie-in with Dialect here is that they coordinate with the Dialect to
> > figure out its capabilities and syntax. What I'd rather see is an
> > externalization of this DDL rendering. There are many parts to this and
> > it is in no way trivial. But the basic "externalize the DDL generation
> > code" should not be overly complex.
> >
> > I too had been considering some similar form of cleanup. The ones I had
> > considered were things like grouping together various "purpose oriented"
> > methods into componentized contracts. The ones I mentioned to you to
> > give example were the methods pertaining to a dialects IDENTITY support
> > and its sequence support. So I'd imagine something like:
> >
> > public interface IdentitySupport {
> > public boolean supportsIdentityColumns();
> > public boolean supportsInsertSelectIdentity();
> > ...
> > }
> >
> > public interface SequenceSupport {
> > public boolean supportsSequences();
> > public boolean supportsPooledSequences();
> > ...
> > }
> >
> > The Dialect contract could then be changed to return these contracts.
> > But this is all really secondary to what you want to achieve. For your
> > purposes, you are really just interested in the DDL generator piece.
> > For that I had envisioned asking the Dialect to get its DDL generation
> > delegate; maybe something like:
> > class Dialect {
> > ...
> > public DDLGenerator getDDLGenerator() {
> > return ...;
> > }
> > }
> >
> > But I never got the chance to completely think this all through. There
> > are lots of design questions that need to be addressed. Stuff like does
> > the delegate contract allow for both create/drop and alter usages? Or
> > do we ask the Dialect for a delegate for each usage? At what
> > granularity do we generate DDL commands? And if say at the granularity
> > of each Table etc, how do we account for say a table DDL command which
> > includes creating the PK versus one that does not (and therefore needs
> > separate DDL)?
> >
> > Anyway, that's about as far as I got.
> >
>
> Well, my primary interest is in DDL, admittedly, but I'm interested in
> the whole Dialect in general.
>
> I still see as necessary a distinction between DML and DDL. I imagine
> one could do such a thing as:
>
> DMLDialect dml = Dialect.getDMLDialect();
>
> if (dml.supportsWhatever()) ...
>
> I haven't had a deep enough look to separate DML from DDL usage yet.
> Most importantly, I don't know where the mechanism to generate DML
> statements is, and how it works.
>
> As to DDL itself, it is basically stateless. If it were only for me
> and my crazy usage scenario (dynamic mappings at runtime), this is the
> way I envision it:
>
> //oldcfg the old Configuration, newcfg the new Configuration - note
> that the basic settings don't change, only the mappings can change
> DDLExecutor ddlexec =
> newcfg.getDDLDialect().generateDDLExecutor(oldcfg, newcfg);
> ddlexec.before();
> // renew SessionFactory with newcfg
> ddlexec.after();
>
> The DDLDialect would have a TableSupport, ColumnSupport,
> SequenceSupport, IdentityColumnSupport, IndexSupport..., and the
> .buildExecutor() would generate a DDLExecutor object (an interface,
> really) with DDL statements that must be executed before renewal of
> the SessionFactory (.before()), because it has been detected that DDL
> changes between oldcfg and newcfg _would_ affect existing Sessions,
> and DDL statements that can be postponed until only after the new
> SessionFactory has ben spawned.
>
> The .generateDDLExecutor would then be in charge of detecting changes
> and call upon the appropriate subdialects (it would call the
> appropriate DDL "fragments", say, IndexSupport if it sees that an
> index must be added/removed) and generate the appropriate scripts and
> fill the DDLExecutor with said scripts (the ones that must be executed
> before the SessionFactory renewal and the ones that may be delayed
> until after it has been spawned).
>
--
Steve Ebersole <st...@hibernate.org>
Hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
