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). > >

This is what I really want to achieve, though. I'm close to it, really close. The Dialect API, as it exists today, only lacks a few pieces and logical separation to make it easier and fully functional. And it is of high interest for our application, which requires that mappings be dynamic, with no downtime (POJOs are out of the question for such a setup, though, or so I believe, since the ability to compile generated code on the fly is only really integrated with Java 1.6 - but I don't use POJOs...)

I'll come up with specific questions over the weekend concerning the existing code (I use 3.3.1), since some parts remain really obscure to me. I can then come up with proposals, which, I believe, will have to be JDK 1.4 compliant, right?