You say "I use JDO directly, not the low level API. But the key-handling is still dependent on GAE datastore I suppose..." I'm not sure it is. My guess (and again, I don't use JDO/JPA) is that it maintains relationships "manually" using foreign key attributes rather than mapping directly onto the LLAPI hierarchy.
On Wed, Oct 14, 2009 at 11:03 AM, andreas_b <andreas.borg...@gmail.com>wrote: > > Hi. > > Well, the restraint seems to be on the way GAE handles keys. There are > 4 types of keys that can be used, but the only ones that are assigned > an ID by the system is Long, Key and encodedKey. > I want the system to automatically assign an id to new objects that > are created, so that limits me to those choices. > I can't use the Long variant on child objects, so I'm stuck with the > Key/encoded Key string variants, and according to > > http://code.google.com/appengine/docs/java/datastore/creatinggettinganddeletingdata.html#Keys > the system generated key is made up of the entity parent id, among > other things. > > I use JDO directly, not the low level API. But the key-handling is > still dependent on GAE datastore I suppose... > > / Andreas > > On Oct 14, 8:10 am, Roy Smith <roy.smith....@googlemail.com> wrote: > > It sounds like you're reading documentation for the Low Level API. > > I don't use JDO, but I suspect that JDO does not have that single-parent > > constraint. > > > > On Tue, Oct 13, 2009 at 8:49 PM, andreas_b <andreas.borg...@gmail.com > >wrote: > > > > > > > > > Hi all. > > > > > I've only been working with relational databases up to now, and have > > > some problems with JDO. > > > > > I seem to have some trouble grasping the basic design patterns with > > > POJO/JDO here. > > > This is probably a very basic issue, but its hard when the mind is > > > setup to think from an entirely different perspective :-). > > > > > So, what I want to do here is to have child objects of the same type > > > referenced from different parents. > > > For example... > > > > > Say we have a class Person, class CarRegister, class Car. > > > > > A Car class with a Key. > > > > > class Car { > > > > > @PrimaryKey > > > @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > > > private Key key; > > > > > ...other persistent objects... > > > > > } > > > > > In Person, I have a list of Car objects that the person owns. > > > > > class Person { > > > > > @PrimaryKey > > > @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > > > private Long id; > > > @Persistent > > > private List<Car> ownedCars; > > > > > } > > > > > In CarRegister, I also have a list of all Car objects registered. > > > > > class CarRegister{ > > > > > @PrimaryKey > > > @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) > > > private Long id; > > > @Persistent > > > private List<Car> registeredCars; > > > > > } > > > > > Is this possible? The documentation seem to suggest that a key is made > > > up of the entity parent id and some other stuff, which should mean > > > that the above wouldn't work. (The key value includes the key of the > > > entity group parent (if any) and either the app-assigned string ID or > > > the system-generated numeric ID). > > > > > I could of course save a list of keys/ids to Car objects instead, but > > > that to me would kind of defeat the purpose of this kind of database. > > > So I want a List of Car objects in both Person and CarRegister, and > > > they must somehow share the same objects in the database. This must be > > > one of the basic use cases, but I have been unable to find an optimal > > > solution for it. > > > > > Thanks in advance. > > > > > BR, Andreas > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
