[Hibernate] Roadmap

[Steve E. <ste...@jb...>]

Now that 3.2.0.ga is imminent, here are the things which are currently
underway, or which I would like to start soon:

1) Antlr query translator redesign.  The original Antlr-based translator
was a great first cut and showed us the usefulness of Antlr for this
task; in many ways it ways a learning experience.  Now, it is time to
take those experiences and redesign how the translator works in a few
areas and to add some significant enhancements.  This will be the
subject of a separate email a little later.  This work is already well
underway on a separate branch in SVN.

2) Adding the notion of a component "persister".  The goal here is to
move most of the logic off of ComponentType to a "persister" managed by
the session factory.  The impetus being twofold:
a) certain hibernate configuration parameters are currently considered
"global" because of the way ComponentType currently works; the two most
annoying being 'hibernate.bytecode.use_reflection_optimizer' and
'hibernate.bytecode.provider'.  These changes would allow both of those
settings to become session factory scoped values.
b) general code cleanup and encapsulation; this aligns with how entities
are managed by the EntityTypes.
More about this in a later email also.  Note that many pre-requisite
changes for this have already been made on HEAD (i.e. the inclusion of
the o.h.tuple.ComponentMetamodel).

3) Redefine how CacheProvider/Cache work.  The main goal here is to have
CacheProvider be able to create Cache instances configured for how
Hibernate uses the different second level (L2) cache regions.  There are
4 regions "types" each with slightly different usage semantics:
a) entity data cache - used to cache entity tuple state
b) collection cache - used to cache collection state
c) query cache - used to cache query results
d) invalidation or timestamps cache

4) Criteria API enhancements:
a) I'd like to get everything that is currently possible in HQL as a
capability in Criteria queries.  Ideally, I'd like to re-use some of the
changes being made to the Antlr query translator to facilitate these
enhancements.
b) statistics collection - the only real possibility I see here is to
expose the ability to name criteria queries and expose the stats based
on the given name.

5) Completion of the EntityMode and Tuplizer capabilities.  This has
been hanging around for a while now.  There are a couple of specific
things we need to finish off here:
a) we know that recognizing the concrete type of polymorphic
associations is completely broken when using the dom4j entity mode.
This is because we currently do not require that node names be unique
and we also do not require that the DOM node contain any type of
discrimination value.  Need to decide on the approach that allows this
to work and that is hopefully non-invasive.
b) allow user defined entity modes.  The infrastructure for allowing
this is now in place in HEAD.  However, there are currently a lot of
places in the code base that assume the entity modes are enums and do =
=3D=3D
type comparisions.  We either need to change all those, or somehow make
the user register their custom entity modes.  Plus the DTD then needs to
be updated to support this.

Another thing to discuss is whether these should be bundled in the 3.2.x
series, or to go with a 3.3.x.  I personally vote to go with a 3.3.x
series as 3.2.x was essentially targetting JPA-related work.  If we
agree for 3.3, then I'll branch HEAD off onto a 3.2 specific branch and
we can start to use HEAD for 3.3 work.

Thoughts?