[
https://issues.apache.org/jira/browse/OPENJPA-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734253#action_12734253
]
Kevin Sutter commented on OPENJPA-1188:
---------------------------------------
A bit more exchange on the forum...
>On Wed, Jul 22, 2009 at 5:37 AM, Adam Hardy <[email protected]>
>wrote:
>
>> Kevin Sutter on 21/07/09 14:42, wrote:
>>
>>
>> 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.
>>
>
> I thought putting code in your entities' setters and getters was
> considered bad practice. Are you saying that there is much code >in OpenJPA
> to cater for this kind of thing?
You are correct. Putting code in an entity's setters and getters is not a best
practice. But, it's not forbidden either. OpenJPA actually logs a warning
message when this situation is detected. But, we do not prevent it. Nor does
the JPA spec forbid it.
This is actually one of the reasons why I didn't go forward with a patch just
yet. Maybe the resolution will be to harden this warning message and not allow
this type of modifications in the setters if you are using property-based
access. But, to be honest, that seems a bit harsh. If OpenJPA can just be a
tad bit smarter when loading entities from a query result set, then we could
satisfy this request. Even if it's not a best practice.
> 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.
