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 Mon, 12 Mar 2007 19:44:09 GMT

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


Mime
View raw message