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(a)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(a)hibernate.org>
Hibernate.org