Re: [Hibernate] query statistics
On Mon, 28 Nov 2005 16:53:08 +0100, Steve Ebersole <[EMAIL PROTECTED]> wrote: A. You'd get the non-expanded SQL strings. For example "from Animal where description in (:descList)" would return something like "select ... from animal animal0_ where animal0_.description in (?)" Which is just perfect. B. I think that's the reason for the '_' character ;) yeah i guess so - i just wanted something that made it very easy to deduct the original name. with a _ prefix I would need some more vodoo power than _originalName_1_ would need ;) /max -Original Message- From: Max Andersen Sent: Monday, November 28, 2005 9:49 AM To: Steve Ebersole; Gavin King; Hibernate devel Subject: Re: [Hibernate] query statistics On Mon, 28 Nov 2005 16:11:21 +0100, Steve Ebersole <[EMAIL PROTECTED]> wrote: So some things to consider then: A. You will only really, truly be able to get the SQL(s) after all parameters values are known (accounting for parameter-lists) And if I call getSQLStatements before parameters are set what then ? I would like call it before I know all parameters...but I guess I *could* also just tell the users they need to fill in the parameters before they can see the SQL - but it would definitly be more userfriendly if it were not required to get a basic hint on what sql they would get. B. Parameter-lists will again cause you problems here. This is because the original parameter name is no longer known by the time the query gets to the translator, thus it is not in the parameter-metadata handed to the QueryImpl. The parameter metadata contains the expanded list of names (i.e., "originalName0_", "originalName1_",...). That I'm probably willing to just say its "unsupported" - but I guess I could deduce it from the parameter names what the originalName were..especially if we made the name more unique/obscure - like "!originalName!0_" or something. /max From: Max Andersen Sent: Thursday, November 24, 2005 6:05 AM To: Steve Ebersole; Gavin King; Hibernate devel Subject: RES: [Hibernate] query statistics just a quick response. the priorities for the tools is: A. get the underlying sql(s) B. get the guessed types of the parameters C. get the locations of the parameters in HQL and SQL A and B is most important (and should be gettable without actually executing the query), C is not important since I can, at least for HQL, aproximate this. So dont let C hold a better solution back if that is the case. ;max De: [EMAIL PROTECTED] em nome de Steve Ebersole Enviada: qui 24-11-2005 03:53 Para: Gavin King; Hibernate devel Assunto: RE: [Hibernate] query statistics Well more I was thinking of delaying the param-list expansion until execution-time and handling it behind either the query-plan or the translators. There is an issue with the tools (or clients of Query in general) getting access to the actual sql to be performed. Essentially, it would not be available until after all parameter lists have been set. But afaict, this is the case regardless of which approach we choose here. So the other option would be to keep param list expansion in AbstractQueryImpl, but then pass both the "source query" and the "expanded query" to locate the query plan; the "source query" really only being used for statistics. Another issue here (though afaict this only affects tools) is proper resolution of named parameter locations corresponding to parameter-lists. This is due to the fact that, in the current setup, the translator only ever knows about the expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:55 AM To: Steve Ebersole; 'Hibernate devel' Subject: RE: [Hibernate] query statistics Right. The only downside would be increased mem usage, I suppose. -Original Message- From: Steve Ebersole Sent: Monday, November 21, 2005 6:54 AM To: Gavin King; 'Hibernate devel' Subject: RE: [Hibernate] query statistics I guess we could make it so. This issue is that currently it does not know the non-expanded query. -----Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:51 AM To: Steve Ebersole; Hibernate devel Subject: RE: [Hibernate] query statistics Could the query plan cache both expanded and non-expanded SQL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, November 21, 2005 6:49 AM To: Hibernate devel Subject: [Hibernate] query statistics In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query stri
RE: [Hibernate] query statistics
A. You'd get the non-expanded SQL strings. For example "from Animal where description in (:descList)" would return something like "select ... from animal animal0_ where animal0_.description in (?)" B. I think that's the reason for the '_' character ;) -Original Message- From: Max Andersen Sent: Monday, November 28, 2005 9:49 AM To: Steve Ebersole; Gavin King; Hibernate devel Subject: Re: [Hibernate] query statistics On Mon, 28 Nov 2005 16:11:21 +0100, Steve Ebersole <[EMAIL PROTECTED]> wrote: > So some things to consider then: > > A. You will only really, truly be able to get the SQL(s) after all > parameters values are known (accounting for parameter-lists) And if I call getSQLStatements before parameters are set what then ? I would like call it before I know all parameters...but I guess I *could* also just tell the users they need to fill in the parameters before they can see the SQL - but it would definitly be more userfriendly if it were not required to get a basic hint on what sql they would get. > B. Parameter-lists will again cause you problems here. This is because > the original parameter name is no longer known by the time the query > gets to the translator, thus it is not in the parameter-metadata handed > to the QueryImpl. The parameter metadata contains the expanded list of > names (i.e., "originalName0_", "originalName1_",...). That I'm probably willing to just say its "unsupported" - but I guess I could deduce it from the parameter names what the originalName were..especially if we made the name more unique/obscure - like "!originalName!0_" or something. /max > > > From: Max Andersen > Sent: Thursday, November 24, 2005 6:05 AM > To: Steve Ebersole; Gavin King; Hibernate devel > Subject: RES: [Hibernate] query statistics > > just a quick response. > > the priorities for the tools is: > > A. get the underlying sql(s) > B. get the guessed types of the parameters > C. get the locations of the parameters in HQL and SQL > > A and B is most important (and should be gettable without actually > executing the query), > C is not important since I can, at least for HQL, aproximate this. > > So dont let C hold a better solution back if that is the case. > > ;max > > ____ > De: [EMAIL PROTECTED] em nome de Steve Ebersole > Enviada: qui 24-11-2005 03:53 > Para: Gavin King; Hibernate devel > Assunto: RE: [Hibernate] query statistics > Well more I was thinking of delaying the param-list expansion until > execution-time and handling it behind either the query-plan or the > translators. > > There is an issue with the tools (or clients of Query in general) > getting access to the actual sql to be performed. Essentially, it would > not be available until after all parameter lists have been set. But > afaict, this is the case regardless of which approach we choose here. > > So the other option would be to keep param list expansion in > AbstractQueryImpl, but then pass both the "source query" and the > "expanded query" to locate the query plan; the "source query" really > only being used for statistics. > > Another issue here (though afaict this only affects tools) is proper > resolution of named parameter locations corresponding to > parameter-lists. This is due to the fact that, in the current setup, > the translator only ever knows about the expanded query. > > -Original Message- > From: Gavin King > Sent: Monday, November 21, 2005 8:55 AM > To: Steve Ebersole; 'Hibernate devel' > Subject: RE: [Hibernate] query statistics > > Right. The only downside would be increased mem usage, I suppose. > > -Original Message- > From: Steve Ebersole > Sent: Monday, November 21, 2005 6:54 AM > To: Gavin King; 'Hibernate devel' > Subject: RE: [Hibernate] query statistics > > I guess we could make it so. This issue is that currently it does not > know the non-expanded query. > > -Original Message- > From: Gavin King > Sent: Monday, November 21, 2005 8:51 AM > To: Steve Ebersole; Hibernate devel > Subject: RE: [Hibernate] query statistics > > Could the query plan cache both expanded and non-expanded SQL? > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve > Ebersole > Sent: Monday, November 21, 2005 6:49 AM > To: Hibernate devel > Subject: [Hibernate] query statistics > > In relation to > http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 > (Statistics for HQL queries use pre-processed quer
Re: [Hibernate] query statistics
On Mon, 28 Nov 2005 16:11:21 +0100, Steve Ebersole <[EMAIL PROTECTED]> wrote: So some things to consider then: A. You will only really, truly be able to get the SQL(s) after all parameters values are known (accounting for parameter-lists) And if I call getSQLStatements before parameters are set what then ? I would like call it before I know all parameters...but I guess I *could* also just tell the users they need to fill in the parameters before they can see the SQL - but it would definitly be more userfriendly if it were not required to get a basic hint on what sql they would get. B. Parameter-lists will again cause you problems here. This is because the original parameter name is no longer known by the time the query gets to the translator, thus it is not in the parameter-metadata handed to the QueryImpl. The parameter metadata contains the expanded list of names (i.e., "originalName0_", "originalName1_",...). That I'm probably willing to just say its "unsupported" - but I guess I could deduce it from the parameter names what the originalName were..especially if we made the name more unique/obscure - like "!originalName!0_" or something. /max From: Max Andersen Sent: Thursday, November 24, 2005 6:05 AM To: Steve Ebersole; Gavin King; Hibernate devel Subject: RES: [Hibernate] query statistics just a quick response. the priorities for the tools is: A. get the underlying sql(s) B. get the guessed types of the parameters C. get the locations of the parameters in HQL and SQL A and B is most important (and should be gettable without actually executing the query), C is not important since I can, at least for HQL, aproximate this. So dont let C hold a better solution back if that is the case. ;max De: [EMAIL PROTECTED] em nome de Steve Ebersole Enviada: qui 24-11-2005 03:53 Para: Gavin King; Hibernate devel Assunto: RE: [Hibernate] query statistics Well more I was thinking of delaying the param-list expansion until execution-time and handling it behind either the query-plan or the translators. There is an issue with the tools (or clients of Query in general) getting access to the actual sql to be performed. Essentially, it would not be available until after all parameter lists have been set. But afaict, this is the case regardless of which approach we choose here. So the other option would be to keep param list expansion in AbstractQueryImpl, but then pass both the "source query" and the "expanded query" to locate the query plan; the "source query" really only being used for statistics. Another issue here (though afaict this only affects tools) is proper resolution of named parameter locations corresponding to parameter-lists. This is due to the fact that, in the current setup, the translator only ever knows about the expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:55 AM To: Steve Ebersole; 'Hibernate devel' Subject: RE: [Hibernate] query statistics Right. The only downside would be increased mem usage, I suppose. -Original Message- From: Steve Ebersole Sent: Monday, November 21, 2005 6:54 AM To: Gavin King; 'Hibernate devel' Subject: RE: [Hibernate] query statistics I guess we could make it so. This issue is that currently it does not know the non-expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:51 AM To: Steve Ebersole; Hibernate devel Subject: RE: [Hibernate] query statistics Could the query plan cache both expanded and non-expanded SQL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, November 21, 2005 6:49 AM To: Hibernate devel Subject: [Hibernate] query statistics In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query strings before any processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to
RE: [Hibernate] query statistics
So some things to consider then: A. You will only really, truly be able to get the SQL(s) after all parameters values are known (accounting for parameter-lists) B. Parameter-lists will again cause you problems here. This is because the original parameter name is no longer known by the time the query gets to the translator, thus it is not in the parameter-metadata handed to the QueryImpl. The parameter metadata contains the expanded list of names (i.e., "originalName0_", "originalName1_",...). From: Max Andersen Sent: Thursday, November 24, 2005 6:05 AM To: Steve Ebersole; Gavin King; Hibernate devel Subject: RES: [Hibernate] query statistics just a quick response. the priorities for the tools is: A. get the underlying sql(s) B. get the guessed types of the parameters C. get the locations of the parameters in HQL and SQL A and B is most important (and should be gettable without actually executing the query), C is not important since I can, at least for HQL, aproximate this. So dont let C hold a better solution back if that is the case. ;max De: [EMAIL PROTECTED] em nome de Steve Ebersole Enviada: qui 24-11-2005 03:53 Para: Gavin King; Hibernate devel Assunto: RE: [Hibernate] query statistics Well more I was thinking of delaying the param-list expansion until execution-time and handling it behind either the query-plan or the translators. There is an issue with the tools (or clients of Query in general) getting access to the actual sql to be performed. Essentially, it would not be available until after all parameter lists have been set. But afaict, this is the case regardless of which approach we choose here. So the other option would be to keep param list expansion in AbstractQueryImpl, but then pass both the "source query" and the "expanded query" to locate the query plan; the "source query" really only being used for statistics. Another issue here (though afaict this only affects tools) is proper resolution of named parameter locations corresponding to parameter-lists. This is due to the fact that, in the current setup, the translator only ever knows about the expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:55 AM To: Steve Ebersole; 'Hibernate devel' Subject: RE: [Hibernate] query statistics Right. The only downside would be increased mem usage, I suppose. -Original Message- From: Steve Ebersole Sent: Monday, November 21, 2005 6:54 AM To: Gavin King; 'Hibernate devel' Subject: RE: [Hibernate] query statistics I guess we could make it so. This issue is that currently it does not know the non-expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:51 AM To: Steve Ebersole; Hibernate devel Subject: RE: [Hibernate] query statistics Could the query plan cache both expanded and non-expanded SQL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, November 21, 2005 6:49 AM To: Hibernate devel Subject: [Hibernate] query statistics In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query strings before any processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certifi
RES: [Hibernate] query statistics
Title: RE: [Hibernate] query statistics just a quick response. the priorities for the tools is: A. get the underlying sql(s) B. get the guessed types of the parameters C. get the locations of the parameters in HQL and SQL A and B is most important (and should be gettable without actually executing the query), C is not important since I can, at least for HQL, aproximate this. So dont let C hold a better solution back if that is the case. ;max De: [EMAIL PROTECTED] em nome de Steve EbersoleEnviada: qui 24-11-2005 03:53Para: Gavin King; Hibernate develAssunto: RE: [Hibernate] query statistics Well more I was thinking of delaying the param-list expansion untilexecution-time and handling it behind either the query-plan or thetranslators.There is an issue with the tools (or clients of Query in general)getting access to the actual sql to be performed. Essentially, it wouldnot be available until after all parameter lists have been set. Butafaict, this is the case regardless of which approach we choose here.So the other option would be to keep param list expansion inAbstractQueryImpl, but then pass both the "source query" and the"expanded query" to locate the query plan; the "source query" reallyonly being used for statistics.Another issue here (though afaict this only affects tools) is properresolution of named parameter locations corresponding toparameter-lists. This is due to the fact that, in the current setup,the translator only ever knows about the expanded query.-Original Message-From: Gavin KingSent: Monday, November 21, 2005 8:55 AMTo: Steve Ebersole; 'Hibernate devel'Subject: RE: [Hibernate] query statisticsRight. The only downside would be increased mem usage, I suppose.-Original Message-From: Steve EbersoleSent: Monday, November 21, 2005 6:54 AMTo: Gavin King; 'Hibernate devel'Subject: RE: [Hibernate] query statisticsI guess we could make it so. This issue is that currently it does notknow the non-expanded query.-Original Message-From: Gavin KingSent: Monday, November 21, 2005 8:51 AMTo: Steve Ebersole; Hibernate develSubject: RE: [Hibernate] query statisticsCould the query plan cache both expanded and non-expanded SQL?-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of SteveEbersoleSent: Monday, November 21, 2005 6:49 AMTo: Hibernate develSubject: [Hibernate] query statisticsIn relation tohttp://opensource2.atlassian.com/projects/hibernate/browse/HHH-73(Statistics for HQL queries use pre-processed query string):The original issue behind this case is now easy to fix because of theintroduction of query plans. The query plans know about the querystrings before any processing has occurred. So simply moving the statsAPI calls into the query plans will get around the mentioned issue.However, I brought up another point there regarding parameter-listexpansion. Currently, this is done within the QueryImpls, such that theexpansion has occurred before the query string even gets to queryplans/translators. This leads to scenarios where the HQL:"from Animal where description in (:descriptionList)"Results in different statistics being tracked based on the number ofparameters actually contained in the bound descriptionList.To me, for the same arguments as the original issue, it is non-intuitiveto issue "from Animal where description in (:descriptionList)" as an HQLquery, but to see things like "from Animal where description in(:descriptionList0_, :descriptionList1_)" in the statistics.The flip side of this is that "correcting" this behavior means delayinggeneration of the actual SQL until the QueryParameters are actuallyknown. AFAICT, this really only effects the tools since the tools wantto display the translated SQL within the console; however, the SQL maynot be fully resolvable at that point in time if we start delaying theresolution of the SQL till execution.So I wanted to open this up for discussion. What makes the most sensehere? ---This SF.Net email is sponsored by the JBoss Inc. Get Certified TodayRegister for a JBoss Training Course. Free Certification Exam for AllTraining Attendees Through End of 2005. For more info visit:http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick___hibernate-devel mailing listhibernate-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/hibernate-devel---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems? Stop! Download the new AJAX search engine that makessearching your log files as easy as surfing the web. DOWNLOAD SPLUNK!http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick__
RE: [Hibernate] query statistics
Well more I was thinking of delaying the param-list expansion until execution-time and handling it behind either the query-plan or the translators. There is an issue with the tools (or clients of Query in general) getting access to the actual sql to be performed. Essentially, it would not be available until after all parameter lists have been set. But afaict, this is the case regardless of which approach we choose here. So the other option would be to keep param list expansion in AbstractQueryImpl, but then pass both the "source query" and the "expanded query" to locate the query plan; the "source query" really only being used for statistics. Another issue here (though afaict this only affects tools) is proper resolution of named parameter locations corresponding to parameter-lists. This is due to the fact that, in the current setup, the translator only ever knows about the expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:55 AM To: Steve Ebersole; 'Hibernate devel' Subject: RE: [Hibernate] query statistics Right. The only downside would be increased mem usage, I suppose. -Original Message- From: Steve Ebersole Sent: Monday, November 21, 2005 6:54 AM To: Gavin King; 'Hibernate devel' Subject: RE: [Hibernate] query statistics I guess we could make it so. This issue is that currently it does not know the non-expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:51 AM To: Steve Ebersole; Hibernate devel Subject: RE: [Hibernate] query statistics Could the query plan cache both expanded and non-expanded SQL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, November 21, 2005 6:49 AM To: Hibernate devel Subject: [Hibernate] query statistics In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query strings before any processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] query statistics
On Mon, 21 Nov 2005 15:55:22 +0100, Gavin King <[EMAIL PROTECTED]> wrote: Right. The only downside would be increased mem usage, I suppose. Done right it would only be in the cases of where its actually needed and even in that case it would only be *one* extra original query that you keep around. Not any big increase - i think. /max -Original Message- From: Steve Ebersole Sent: Monday, November 21, 2005 6:54 AM To: Gavin King; 'Hibernate devel' Subject: RE: [Hibernate] query statistics I guess we could make it so. This issue is that currently it does not know the non-expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:51 AM To: Steve Ebersole; Hibernate devel Subject: RE: [Hibernate] query statistics Could the query plan cache both expanded and non-expanded SQL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, November 21, 2005 6:49 AM To: Hibernate devel Subject: [Hibernate] query statistics In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query strings before any processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ 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] --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] query statistics
Right. The only downside would be increased mem usage, I suppose. -Original Message- From: Steve Ebersole Sent: Monday, November 21, 2005 6:54 AM To: Gavin King; 'Hibernate devel' Subject: RE: [Hibernate] query statistics I guess we could make it so. This issue is that currently it does not know the non-expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:51 AM To: Steve Ebersole; Hibernate devel Subject: RE: [Hibernate] query statistics Could the query plan cache both expanded and non-expanded SQL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, November 21, 2005 6:49 AM To: Hibernate devel Subject: [Hibernate] query statistics In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query strings before any processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] query statistics
I guess we could make it so. This issue is that currently it does not know the non-expanded query. -Original Message- From: Gavin King Sent: Monday, November 21, 2005 8:51 AM To: Steve Ebersole; Hibernate devel Subject: RE: [Hibernate] query statistics Could the query plan cache both expanded and non-expanded SQL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, November 21, 2005 6:49 AM To: Hibernate devel Subject: [Hibernate] query statistics In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query strings before any processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] query statistics
Could the query plan cache both expanded and non-expanded SQL? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, November 21, 2005 6:49 AM To: Hibernate devel Subject: [Hibernate] query statistics In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query strings before any processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] query statistics
In relation to http://opensource2.atlassian.com/projects/hibernate/browse/HHH-73 (Statistics for HQL queries use pre-processed query string): The original issue behind this case is now easy to fix because of the introduction of query plans. The query plans know about the query strings before any processing has occurred. So simply moving the stats API calls into the query plans will get around the mentioned issue. However, I brought up another point there regarding parameter-list expansion. Currently, this is done within the QueryImpls, such that the expansion has occurred before the query string even gets to query plans/translators. This leads to scenarios where the HQL: "from Animal where description in (:descriptionList)" Results in different statistics being tracked based on the number of parameters actually contained in the bound descriptionList. To me, for the same arguments as the original issue, it is non-intuitive to issue "from Animal where description in (:descriptionList)" as an HQL query, but to see things like "from Animal where description in (:descriptionList0_, :descriptionList1_)" in the statistics. The flip side of this is that "correcting" this behavior means delaying generation of the actual SQL until the QueryParameters are actually known. AFAICT, this really only effects the tools since the tools want to display the translated SQL within the console; however, the SQL may not be fully resolvable at that point in time if we start delaying the resolution of the SQL till execution. So I wanted to open this up for discussion. What makes the most sense here? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
