[jira] Issue Comment Edited: (OPENJPA-1188) Simple Select generates extra SQL statements to populate Entities

["Kevin Sutter (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OPENJPA-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733772#action_12733772 ] 

Kevin Sutter edited comment on OPENJPA-1188 at 7/22/09 12:05 PM:
-----------------------------------------------------------------

Attaching a 2.0 (trunk) testcase patch for reproducing this problem (although since the patch is only adding two new testcases, it should be useable for any level of OpenJPA).

      was (Author: kwsutter):
    Attaching a 2.0 (trunk) testcase patch for reproducing this problem.
  
> Simple Select generates extra SQL statements to populate Entities
> -----------------------------------------------------------------
>
>                 Key: OPENJPA-1188
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1188
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.2.2, 1.3.0, 2.0.0-M1, 2.0.0-M2, 2.0.0
>            Reporter: Kevin Sutter
>         Attachments: openjpa-1188-testcase.patch
>
>
> This JIRA is the result of a discussion on our users forum:
> http://n2.nabble.com/openJPA-generates-select-per-row---impossible-to-use-for-simple-select-statements-td3261512.html#a3261512
> Mikhail was very helpful (and patient) with helping to reproduce the problem.  I will be posting a testcase patch very soon.  The actual fix may be left up to a potential contributor or committer...  :-)
> Requirements...
> o  Your Entity needs to have an attribute that OpenJPA wrappers with a proxy.  This proxy is used to detect changes to these object types.  Example object types that OpenJPA wrappers are Calendar (culprit for this scenario), Date, Collection, and Map.
> o  In the Setter method for the proxied attribute, you must modify the value getting set.  In this scenario, the Calendar object was being modified in the setDate method via the set() method.
> o  The Entity must be using property-based access (annotations on the Getter methods).
> o  The Persistence Context must be clear of any Entities that are being queried.  For example, my testcase was persisting several Entities before executing the Query that was supposedly generating the extra SQL statements.  If I didn't clear the Persistence Context before executing the Query, the Entities were already populated and it didn't trigger the extra SQL statements.
> o  And, now comes the magic...  :-)  Access to the attribute's meta data seems to be done alphabetically.  From what I can tell, this seems to be a Java format convention.  In any case, the extra SQL statements are used to re-populate any attributes that are alphabetically after the proxied attribute that was modified in the corresponding Setter method.
> Given all of that setup, here's an explanation of what's happening...
> After the initial query is executed, the resulting Entity objects need to be populated with the data returned by the query.  When the setter was called for this proxied attribute, and the value was modified, this attribute (and the Entity) was marked as being "dirty".  Part of the dirty processing is to determine which fields need to be re-loaded.  Of course, the proxied attribute does not have to be re-loaded since it was in the process of being modified.  The id field does not have to re-loaded since we're using id generation for this particular scenario.  And, any fields that are alphabetically before the proxied attribute were just loaded, so they don't have to be re-loaded.  But, any fields that come after the proxied attribute (alphabetically) don't realize that they will be loaded (due to the original query), so the extra SQL is pushed out to load these fields.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.