openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] Created: (OPENJPA-1188) Simple Select generates extra SQL statements to populate Entities
Date Tue, 21 Jul 2009 13:51:14 GMT
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.2.1, 1.2.0, 1.1.0, 1.0.3, 1.0.2, 1.0.1, 1.0.0, 1.0.4, 1.0.5, 1.1.1,
1.2.2, 1.3.0, 2.0.0-M1, 2.0.0-M2, 2.0.0
            Reporter: Kevin Sutter


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.


Mime
View raw message