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

Reply via email to