openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <>
Subject [jira] Updated: (OPENJPA-1188) Simple Select generates extra SQL statements to populate Entities
Date Tue, 21 Jul 2009 18:36:14 GMT


Kevin Sutter updated OPENJPA-1188:

    Attachment: openjpa-1188-testcase.patch

Attaching a 2.0 (trunk) testcase patch for reproducing this problem.

> Simple Select generates extra SQL statements to populate Entities
> -----------------------------------------------------------------
>                 Key: OPENJPA-1188
>                 URL:
>             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:
> 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.

View raw message