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