[hibernate-dev] Wishing to work on Hibernate's DDL capabilities

[Steve Ebersole]

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 <steve at 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 <steve at hibernate.org>
Hibernate.org