Antlr3 is currently still beta.  There are some very nice new features
(like the tree construction rewrite rules).  Not sure, we'll have to
watch and see how it progresses.  They also have an IDE for this series,
btw ;)

Well you say 3.3 is more appropriate for the antlr (#1) and tuplizer
(#5) stuff, but the rest should be 3.2.x.  But the Criteria stuff (#4)
is dependant upon the antlr stuff.  The cache provider changes I think
are clearly inappropriate for a point release.  So that just leaves a
question about the component persisters. 

-----Original Message-----
From: Max Andersen 
Sent: Monday, July 17, 2006 9:50 AM
To: Steve Ebersole; Hibernate development
Subject: Re: [Hibernate] Roadmap


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

This is probably out-of-the-question, but here it goes:

Have you looked into if antlr3 could help us in anyway ?
One thing I understood from their release notes is that they now
have a clear distinction between generationtime and runtime resulting
in a smaller footprint and easier isolation.

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

in context of wether this should go to 3.3 or 3.2 then a) could be a  
sentiment
for 3.2.something ?

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

+1 for everything currently possible in HQL.

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

sounds fair enough.

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

all sounds good.

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

starting 3.3 sounds like a plan for the antlr changes and entitymode.

/max
>
> Thoughts?
>
>
>
------------------------------------------------------------------------
-
> Using Tomcat but need to do more? Need to support web services,
security?
> Get stuff done quickly with pre-integrated technology to make your job

> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> hibernate-devel mailing list
> hibernate-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
[EMAIL PROTECTED]
http://hibernate.org

JBoss Inc
[EMAIL PROTECTED]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Reply via email to