openjpa-dev mailing list archives

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

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


Mime
View raw message