openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abe White (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-168) sql optimize n rows query hint
Date Tue, 20 Mar 2007 16:04:32 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482421
] 

Abe White commented on OPENJPA-168:
-----------------------------------

Comments on the proposed patch:

- I don't like the whole scheme of setting the expected result count to -1 for anything "artificial".
 It's confusing and unnecessary.  Just set it to the number of expected "primary" results,
and the DBDictionary can invoke sel.hasEagerJoin(true) to figure out if the expected count
can be used.  Or just have the getter for the expected count always return 0 if there is an
eager to-many join (or better yet, turn -1 into a value meaning "unknown" and have it return
-1, which would then also be the default when no expected count is set).  

- I still think there should be a way to get rid of Union.is/setSingleResult by moving the
expected result property to SelectExecutor -- which both Select and Union extend -- and taking
advantage of the new expected result ("1" obviously indicates a single result).  

- If you're going to validate the value of the user-supplied hint in the JPA QueryImpl, you
might as well transform it into a Number at that point before setting it into the FetchConfiguration.
 Also, I'd accept any Number, not just an Integer (technically we should accept any whole
number, but that's a pain to implement).  Then in the JDBC layer, you can just cast the hint
value directly to a Number and forgo validating it and checking for String values a second
time.

- DB2 really cares whether you use "optimize for 1 row" vs. "optimize for 1 rows"?  That's
ugly.

- We should probably generalize the configuration of row optimization to the base DBDictionary
with an override mechanism.

- If you're going to invoke setUnique(true) on the underlying query from the JPA QueryImpl's
getSingleResult, you need to do three things:
  1. Unset it in a finally clause, because the very next call might be to getResultList, and
in general getSingleResult shouldn't have stateful side effects.
  2. Change the kernel's QueryImpl to throw an exception when unique is set but the query
doesn't return any results.  Right now it allows 0 results and will return null, which is
indistinguishable from a projection on a null field that returned 1 result.
  3. Get rid of the code immediately following in getSingleResult that extracts the value
if a List is returned, because after setting the unique flag on the underlying query, it will
never return a List.  

- The hint key should be a constant in the kernel's Query interface or somewhere like that.

> sql optimize n rows query hint
> ------------------------------
>
>                 Key: OPENJPA-168
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-168
>             Project: OpenJPA
>          Issue Type: New Feature
>            Reporter: David Wisneski
>         Assigned To: David Wisneski
>         Attachments: OPENJPA-168.patch.txt
>
>
> There werre various comments from Patrick, Abe and Kevin Sutter about the code that I
checked related to Optimize hint.  So I have gone back and relooked at this and wil be making
some changes.  At Kevin's suggestion I will do this through a JIRA feature so that folks will
have opportunity to comment on this before the code is actually done and checked in.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message