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