On Mon, 17 Jul 2006 17:58:53 +0200, Steve Ebersole <[EMAIL PROTECTED]> wrote:
> 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 ;) Yes - and it actually looks very usefull ;) It would also remove the antlr class collision issues since noone uses it ;) (except of course Drools) > 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. a 2-phased migration as you talked about might be the way forward since the sf-level control of bytecode gen would be good (but i don't know if it is critical-critical?) > > -----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
