As an fyi... I just checked in a bunch of changes related to how queries "translations" are cached. I added a new concept of "query plans" and a QueryPlanCache to encapsulate the role that used to be filled by the building and caching of the QueryTranslator arrays within SessionFactory. This has a number of significant ramifications:
1) HQL queries and collection-filters are now translated as soon as they are encountered (i.e. as soon as createQuery()/createFilter() are called). Two important things to note here: first, grammar problems will now show up immediately as opposed to delayed until first execution. Second, this allows much better "parameter type guessing" within the Query impls when one of the untyped forms of setParameter() is called. Minorly, (although not yet exposed) this also allows the Query impls to no the "source query location" of all parameters (important for the tools). 2) Native-SQL query "translations" are now cached. This caching, however, happens only after first execution since not all pertinent information is known at the time createSQLQuery() is called. Currently, named native-SQL queries are not cached at SF startup, but I'll add that support next week. The SQLQueryImpl also knows its "parameter metadata" just like HQL/collection-filters, but there is not enough information to properly do the "expected type" stuff done in HQL and collection-filters. 3) Allowed me to remove the "evil" initParameterBookkeeping stuff that used to be done on AbstractQueryImpl which should result in some minor performance increases (this stuff used to parse the query string each and every time a Query impl was obtained). 4) Especially for those of you interested in tools development, I created a new class that is responsible for "reconginizing parameters" within query strings in a unified manner. This class, for example, is now used exclusively within the query plans to determine the proper "parameter locations". Essentially, it is a very simple parser with a small pre-defined number of recognized tokens. Have a look at org.hibernate.engine.query.ParameterParser and especially the different impls of org.hibernate.engine.query.ParameterParser$Recognizer. Anyway, all this is still not completely done to my satisfaction, but it's a good start. Because these are some very broad changes, I will plan to go with a 3.1rc3 including this stuff (maybe late next week). The current plan is that 3.1 final will then be the release after that. P.S. part of these changes required a modification to the constructor for AbstractQueryImpl to add a new parameter. There were two constructors on SQLQueryImpl for which I could not find any usages within the Hibernate core code-base. If these effect someone (tools?, annotations?, ejb3?) let me know. Otherwise I actually plan to go back and remove those constructors. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
