[
https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482490
]
Ritika Maheshwari commented on OPENJPA-168:
-------------------------------------------
Abe your comment :
- 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).
The reason for using -1 is that we want to differentiate between cases where
the user added a hint to optimize for 1 row versus where we internally
generated the value (getSingleResult,singleRelationshiptraversal etc).If the
user has specified the optimize for 1 row through hint than we do not want to
check for eagerJoins(true).We basically do not want to do anychecking and just
add the optimize for 1 row clause.
But if the expectedResultCount is computed internally to be a value of 1 then
we want to check the eagerJoins(true) and want to make sure that we are in fact
returning a single row.So the -1 differnetiates the internally generated 1 from
the user's specified 1
Your Comment
We should probably generalize the configuration of row optimization to the base
DBDictionary with an override mechanism.
is contradicting with your earlier comment
4. "getOptimizeClause" seems too generic. I'm also not clear on what use it has
in the base DBDictionary class if you state that individual dictionaries will
still have to override toSelect themselves to insert the optimization SQL.
The fact of the matter is that the optimize clause generation for various
dictionaries is different in terms of syntax and where the clause appears in
the select string.So I am not sure if u really want to generalize the
configuration of row optimization to the base DBDictionary.Although that was
our
original plan
> 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.
