[
https://issues.apache.org/jira/browse/OPENJPA-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480177
]
Abe White commented on OPENJPA-168:
-----------------------------------
1. I think the hint name should be more like
"openjpa.hint.OptimizeResultCount". It should be "hint" and not "hints" to
match the existent "openjpa.hint.OracleSelectHint". And I see no reason to tie
it to SQL.
2. I don't think we need a FetchConfiguration instance variable. For find()
calls and loading hollow objects we always know we're only loading one instance
because we use the StoreManager.load() call internally. There are similar
internal APIs used only when traversing a to-one relation. So the
JDBCStoreManager or relation field strategies can set the proper expected
result count into the Select directly. Much better than having to set a
FetchConfiguration value and then make sure it disappears for subsequent
selects. The only problem is Query.getSingleResult, because right now we
execute the query as a multi-result query and then extract the one result at
the JPA layer. We don't have to do it this way, though. The underlying kernel
Query already has a "Unique" property you can set to indicate a single result.
The property doesn't have quite the semantics we want, because it allows a
query that returns 0 results whereas that's an error in JPA. We can't just
change the Unique semantics because of JDO, but we could certainly make it
configurable on the Query instance whether a Unique query can legally return 0
results. So if we start using the Unique property rather than extracting the
single result at the JPA layer, we'll know when the user is using
getSingleResult when we construct the Select, and we can again set the expected
number of results directly into the Select.
3. The SelectImpl already knows when it has to-many eager joins; no need for
additional state. See SelectImpl.hasEagerJoin(boolean toMany).
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.
> 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
>
> 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.
