[
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.
