Thanks for filing that Max.
I'm kind of interested in your findings because there is another place
where I'm doing about the same thing (i.e. making a RatePlan instance
a direct child of an Entity other than Activity) and it works fine in
that case most of the time. Sometimes it gives me the "oid is not an
instance of javax.jdo.identity.ObjectIdentity" exception.
here's the model:
@PersistenceCapable(identityType=IdentityType.APPLICATION)
public class ActivityReservation extends BaseBean
{
@PrimaryKey
@Persistent(valueStrategy=IdGeneratorStrategy.IDENTITY)
private Key id;
@Embedded(
members={
@Persistent(name="key", column="activityKey"),
@Persistent(name="name", column="name"),
@Persistent(name="pricingModel",
column="pricingModel")
}
)
@Persistent(defaultFetchGroup="true")
private ActivityFK activity;
@Embedded
@Persistent(defaultFetchGroup="true")
private ActivityLaunchFK launch;
@Persistent
private RatePlan ratePlan;
@Persistent
private BigDecimal totalCost;
@Persistent
private List<Guest> guests = new ArrayList<Guest>();
}
and
@PersistenceCapable(identityType=IdentityType.APPLICATION)
public class Reservation extends BaseBean
{
@PrimaryKey
@Persistent(valueStrategy=IdGeneratorStrategy.IDENTITY)
private Key id;
@Persistent
private Set<ActivityReservation> activityReservations = new
HashSet<ActivityReservation>();
@Persistent
private Date createdOn;
@Persistent
private String contactName;
@Persistent
private BigDecimal totalCost;
@Persistent
private BigDecimal totalPaid;
@Persistent
private BigDecimal balanceDue;
}
I'd really like to avoid using a Key instance rather than a RatePlan
instance because I want to ensure that the RatePlan linked to a
BundledActivity or an ActivityReservation is not used anywhere else in
the system. If I allow a Key instance there, someone may be tempted
to put the Key of an un-owned RatePlan which can be edited out of
context. So, I need to make sure I understand this limitation: if
class A has an instance (or instances) of class B in your data model,
then class C is not allowed to have an instance (or instances) of
class B? I don't remember reading that in any of the docs, but
perhaps I simply missed it. That's kind of a big deal for me. I'm
almost to the point where I can present my proof of concept to the
"higher ups" and then start dedicating time to simply porting our app
to the app-engine, but this may make me step back a bit. Our classes
share a lot of data, usually I can get around this with the XyzFK
pattern used above (i.e. ActivityFK and ActivityLaunchFK), but those
are just foreign keys with denormalized data that allows for either
querying filters, or simple field loading of foreign objects without
loading the full foreign object. I thought that the layout of
BigTable just made rows of child/dependant objects sequentially after
the parent row:
Activity(275) {name:"Foo Bar", .... fieldN:valueN...}
Activity(275)/RatePlan(123) {name:"foo bar Rate", ..... fieldN:valueN...}
Activity(276) {name:"Bar Baz", .... fieldN:valueN...}
Activity(276)/RatePlan(124) {name:"bar baz Rate", ..... fieldN:valueN...}
.....
and that you'd be able to do something like:
Bundle(543) {name:"Foo Bar Bundle", .... fieldN:valueN...}
Bundle(543)/RatePlan(321) {name:"my Rate", ..... fieldN:valueN...}
You can make RatePlan instances without a parent right? I thought I
had a handle on the BigTable layout, but perhaps I am wrong? It would
be really great for me if a particular class could be a field on more
than one parent containing class, *not the same instance*, but just
the same type. Is there any other way (besides just using Key
instances) you can think of that would accomplish what I am after?
thanks again,
-bryce
On Tue, Dec 8, 2009 at 7:21 PM, Max Ross (Google)
<maxr+appeng...@google.com> wrote:
> Filed http://code.google.com/p/datanucleus-appengine/issues/detail?id=170
>
> On Tue, Dec 8, 2009 at 6:18 PM, Max Ross (Google)
> <maxr+appeng...@google.com> wrote:
>>
>> Ok I think I know what's going on. First here's a stripped down version
>> of your object model with the bare minimum needed to reproduce the
>> exception:
>>
>> @PersistenceCapable(identityType = IdentityType.APPLICATION)
>> public class RatePlan {
>> @PrimaryKey
>> @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
>> private Key id;
>> }
>>
>> @PersistenceCapable(identityType = IdentityType.APPLICATION)
>> public class Activity {
>> @PrimaryKey
>> @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
>> private Key id;
>>
>> @Persistent
>> private List<RatePlan> ratePlans = new ArrayList<RatePlan>();
>> }
>>
>> @PersistenceCapable(identityType = IdentityType.APPLICATION)
>> public class Bundle {
>> @PrimaryKey
>> @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
>> private Key id;
>>
>> @Persistent
>> private RatePlan ratePlan;
>>
>> public void setRatePlan(RatePlan ratePlan) {
>> this.ratePlan = ratePlan;
>> }
>> }
>>
>> And here's the unit test I turned your code into that generates the
>> exception:
>> public void testBryce() {
>> pm.newQuery(Activity.class).execute();
>>
>> Bundle bundle = new Bundle();
>> bundle.setRatePlan(new RatePlan());
>>
>> pm.makePersistent(bundle);
>> }
>>
>> I believe the issue is that RatePlan is owned by two different objects in
>> your model - Bundle and Activity. Due to the nature of primary keys in the
>> app engine datastore, a class can only have a single owner. We detect other
>> flavors of this scenario when the entity meta-data is loaded but not this
>> particular variant. I'll file a bug and try to produce a useful exception.
>> To work around this you'll need to either switch Activity.ratePlans or
>> Bundle.ratePlans to be an unowned relationship and just store the Key of the
>> RatePlan rather than the RatePlan itself. Please give that a try and let me
>> know how it goes.
>>
>> Thanks,
>> Max
>> On Tue, Dec 8, 2009 at 10:19 AM, bryce cottam <bcot...@gmail.com> wrote:
>>>
>>> No worries Max, I'm using 1.2.6 right now, so the "multiple instance" bug
>>> isn't an issue right now. Whenever you get to it is fine. As always I
>>> appreciate your input.
>>>
>>> Thanks
>>> -bryce
>>>
>>> On Dec 8, 2009 10:14 AM, "Max Ross (Google)" <maxr+appeng...@google.com>
>>> wrote:
>>>
>>> Hi Bryce,
>>>
>>> I started digging into you issue and quickly bumped into the "Multiple
>>> relationships of the same type" bug for which I posted the workaround. Then
>>> I got bogged down with unrelated stuff. I have definite plans to get back
>>> to your example today. Thanks for being patient, and sorry this is taking
>>> so long.
>>>
>>> Max
>>>
>>> On Mon, Dec 7, 2009 at 11:35 PM, bcottam <bcot...@gmail.com> wrote: > >
>>> Max, have you had a chance...
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "Google App Engine for Java" group.
>>> To post to this group, send email to
>>> google-appengine-j...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> google-appengine-java+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/google-appengine-java?hl=en.
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Google App Engine for Java" group.
> To post to this group, send email to google-appengine-j...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
