Re: [Hibernate] query plans
Steve Ebersole wrote: 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. Ping me before releasing rc3, I'm making good progress in the naming strategy rework and It's better to have that in a RC. 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. I'll check tomorrow --- 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
Re: [Hibernate] query plans
Nice stuff - give a ping when sql query caching is in there somewhere ;) btw. if you know by heart what you replace sessionFactoryImpl.getQuery(query, false, Collections.EMPTY_MAP); then let me know ;) (or do i need a session now to create a query and get the generated sql etc. ?) /max 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 -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- 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
Re: [Hibernate] query plans
Nice stuff - give a ping when sql query caching is in there somewhere ;) btw. if you know by heart what you replace sessionFactoryImpl.getQuery(query, false, Collections.EMPTY_MAP); then let me know ;) (or do i need a session now to create a query and get the generated sql etc. ?) And if I need a session is it guaranteed it won't need to get a Connection to do its thing as long as i'm just creating queries ? /max /max 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 -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- 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
Re: [Hibernate] query plans
On Sun, 06 Nov 2005 18:52:34 +0100, Max Rydahl Andersen [EMAIL PROTECTED] wrote: Nice stuff - give a ping when sql query caching is in there somewhere ;) btw. if you know by heart what you replace sessionFactoryImpl.getQuery(query, false, Collections.EMPTY_MAP); then let me know ;) (or do i need a session now to create a query and get the generated sql etc. ?) I found it, you have moved it to HQLQueryPlan and encapsulated all the translators, making it inaccessible for the tools to use when showing what the generated sql will look like. I have taken the liberty to add a getTranslators() onto HQLQueryPlan so the tools still can snoop on the core. Let me know if you have a better suggestion ;) /max /max 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 -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- 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
RE: [Hibernate] query plans
SQL query caching is in there... -Original Message- From: Max Andersen Sent: Sunday, November 06, 2005 11:53 AM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] query plans Nice stuff - give a ping when sql query caching is in there somewhere ;) btw. if you know by heart what you replace sessionFactoryImpl.getQuery(query, false, Collections.EMPTY_MAP); then let me know ;) (or do i need a session now to create a query and get the generated sql etc. ?) /max 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 -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- 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
Re: [Hibernate] query plans
SQL query caching is in there... ok - where ? Can't find it. And from your mail it sounded like you would not have this before next week. Currently, named native-SQL queries are not cached at SF startup, but I'll add that support next week. /max -Original Message- From: Max Andersen Sent: Sunday, November 06, 2005 11:53 AM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] query plans Nice stuff - give a ping when sql query caching is in there somewhere ;) btw. if you know by heart what you replace sessionFactoryImpl.getQuery(query, false, Collections.EMPTY_MAP); then let me know ;) (or do i need a session now to create a query and get the generated sql etc. ?) /max 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 -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- 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
RE: [Hibernate] query plans
Yes, try reading what you quoted from me again ;) -Original Message- From: Max Andersen Sent: Sunday, November 06, 2005 3:24 PM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] query plans SQL query caching is in there... ok - where ? Can't find it. And from your mail it sounded like you would not have this before next week. Currently, named native-SQL queries are not cached at SF startup, but I'll add that support next week. /max -Original Message- From: Max Andersen Sent: Sunday, November 06, 2005 11:53 AM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] query plans Nice stuff - give a ping when sql query caching is in there somewhere ;) btw. if you know by heart what you replace sessionFactoryImpl.getQuery(query, false, Collections.EMPTY_MAP); then let me know ;) (or do i need a session now to create a query and get the generated sql etc. ?) /max 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 -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- 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
Re: [Hibernate] query plans
On Mon, 07 Nov 2005 06:00:21 +0100, Steve Ebersole [EMAIL PROTECTED] wrote: Yes, try reading what you quoted from me again ;) eh yes, named native-queries are not cached at SF startup which is the part I were interested in (not just ordinary sql caching). /max -Original Message- From: Max Andersen Sent: Sunday, November 06, 2005 3:24 PM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] query plans SQL query caching is in there... ok - where ? Can't find it. And from your mail it sounded like you would not have this before next week. Currently, named native-SQL queries are not cached at SF startup, but I'll add that support next week. /max -Original Message- From: Max Andersen Sent: Sunday, November 06, 2005 11:53 AM To: Steve Ebersole; Hibernate development Subject: Re: [Hibernate] query plans Nice stuff - give a ping when sql query caching is in there somewhere ;) btw. if you know by heart what you replace sessionFactoryImpl.getQuery(query, false, Collections.EMPTY_MAP); then let me know ;) (or do i need a session now to create a query and get the generated sql etc. ?) /max 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 -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- 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
