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.performRemo
> ve(UnitOfWorkImpl.java:2711)
>
> at
> oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.rem
> ove(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!