Hi Gordon,
On Nov 30, 2005, at 1:23 PM, Gordon Yorke wrote:
> Hello Craig,
> This is how we interpret the specification as well and how
> property access works in TopLink?
> I think perhaps you may be confused by my answer to the
> question Marina had asked about the warning she was seeing.
> Hopefully with more specifics I can clear up your confusion.
Actually, I was confused by the warning itself. But bygones.
> Within TopLink properties are accessed and set through the
> corresponding accessor and mutator only. There is no access to the
> underlying field. In fact with property access there is no way to
> know what field will be used or if there is a field at all.
Good. That's how I interpret it as well.
> The, poorly worded, warning that Marina mentioned is from our
> TopLink 10.1.3 EJB 3.0 Preview support and is applicable only to
> the enhancement of user code to support lazy loading of One-to-one
> (and many-to-one) relationships. In the Preview we chose to extend
> this enhancement to properties in the case that there was an
> underlying field of the same name. This, although not a robust
> choice (it is error prone in cases where the property accessors are
> not simple wrappers of the class fields), provided the majority of
> users with lazy one-to-one property access without much work on our
> end. The warning states that we are unable to enhance the class
> because the property is not a simple wrapper for an underlying
> field. This did not change the way TopLink accesses the properties
> but simply changed the lazy loading behaviour.
I would feel better if you said "improper" instead of "not a robust
choice" because it sounds like you are equating robustness and
correctness, which I would disagree with.
> At this time we have a bug to remove this enhancement and
> provide a robust option for one-to-one mapped properties. This
> work will be completed before the final delivery but as it has yet
> to cause any issues with the testing it has not been a high priority.
> Hopefully I have cleared up your questions?
Yes, thank you.
Craig
> --Gordon
> -----Original Message-----
> From: craig.russell_at_sun.com [mailto:craig.russell_at_sun.com]On Behalf
> Of Craig L Russell
> Sent: Wednesday, November 30, 2005 2:49 PM
> To: persistence_at_glassfish.dev.java.net
> Cc: Marina Vatkina; ejb3-toplink-ext_at_sun.COM
> Subject: "Abstract" persistent properties (without a field of the
> same name)
>
> Hi Gordon,
>
> As we discussed briefly on today's phone conference, I didn't see
> anywhere in the spec that the persistence provider is allowed to
> use a field to store persistent properties. I thought it would be
> good to have an email trail of the discussion.
>
> My understanding is that the fields that back the property belong
> to the user; the provider is only supposed to use the get/set
> methods; and it's just not legal for the provider to access any
> fields except for persistent fields.
>
> Thanks,
>
> Craig
>
> On Nov 29, 2005, at 7:54 AM, Gordon Yorke wrote:
>
>> The property warning is simply a warning notifying the user that
>> because they have choosen to use abstract properties (properties
>> without a field) the relationship will be eagerly retreived. From
>> a functional point of view the end user should not notice a
>> difference. It is also spec compliant as fetch types are
>> suggestions within the Spec.
>>
>> --Gordon
>>
>>
>> -----Original Message-----
>> From: mvatkina_at_ha21sca-mail1.SFBay.Sun.COM
>> [mailto:mvatkina_at_ha21sca-mail1.SFBay.Sun.COM]On Behalf Of Marina
>> Vatkina
>> Sent: Monday, November 28, 2005 8:44 PM
>> To: ejb3-toplink-ext_at_sun.COM; persistence_at_glassfish.dev.java.net
>> Subject: [Fwd: bugs or user error?]
>>
>>
>> Team,
>>
>> This is another email that I've sent on Tuesday
>> with no luck of getting through :(.
>>
>> thanks,
>> -marina
>>
>> -------- Original Message --------
>> Subject: bugs or user error?
>> Date: Tue, 22 Nov 2005 13:20:24 -0800
>> From: Marina Vatkina <marina.vatkina_at_sun.COM>
>> To: "persistence_at_glassfish.dev.java.net"
>> <persistence_at_glassfish.dev.java.net>
>>
>> Team,
>>
>> I encountered the following problems while running my simple test:
>>
>> 1. With property-based persistence (the default, right?), if I do
>> *not*
>> have a field that matches exactly the name of property for lazy
>> loading
>> (e.g. 'cust' vs. getCustomer()), I get the following warning in
>> Java SE
>> (I didn't check Java EE yet):
>>
>> --Weaving for valueholders not enabled for class [entity.Order]
>> because it does
>> not have field [customer].
>>
>> 2. Remove of an instance fetched in the same tx throws an
>> exception that
>> it's detached:
>>
>> Exception in thread "main" java.lang.IllegalArgumentException:
>> Entity must be
>> managed to call remove: entity.Customer_at_10849bc, try merging the
>> detatched and
>> try the remove again.
>> at
>> oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.performRem
>> ove(UnitOfWorkImpl.java:2711)
>>
>> at
>> oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.re
>> move(EntityManagerImpl.java:117)
>>
>> Are these bugs or my errors?
>>
>> thanks,
>> -marina
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell_at_sun.com
> P.S. A good JDO? O, Gasp!
>
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!