On Thu, 2009-06-11 at 22:30 +0200, Francis Galiegue wrote: > > 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...) You must realize that this "splitting" is simply cosmetic; it is not adding any new feature. I was simply considering this because I like tidiness in the form of encapsulation.
As an illustration, take the case of sequences. A dialect's sequence support is really twofold (provided it supports sequences at all): 1) How do we manage them (obtain information about them from the data dictionary and create/drop them)? 2) How do we query them for nextvals? So we have a design decision. Do we split them the way you suggest (which imo is a bit contrived) and say that sequence-management meta-info is part of the "ddl dialect"? Or do we encapsulate the dialect's support of sequences into a contract unto itself (SequenceSupport)? > > 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? 1.4, correct. Also, if the work is "significant" we will need a signed contributor agreement to be able to accept the contribution: http://www.jboss.org/contribute/contributions/index.seam > -- Steve Ebersole <st...@hibernate.org> Hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
