[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-09 Thread James H
Bryce, I tried another use of your embedded class related to Audit fields on an Entity. For consistency in approach to Auditing entity data, typically you would add the following 4 fields to each entity in your design: createBy, createdDate, updatedBy, and updatedDate. I thought I'd place these

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-09 Thread bryce cottam
hey James, I usually do a defaultFetchGroup=true on my embedded classes ('cause I always want them), but this makes it so that the embedded class is always loaded. This generally isn't a problem because embedded values are contained in your entities record in the data store. However, there is

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-05 Thread Rusty Wright
Good points. In my case, so far, the copied objects are small and not complicated, which is why my method appealed to me. I feel like there's some fundamental concept that I'm not getting and it has to do with how objects are mapped onto the Big Table data store. Watching the videos from

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-05 Thread Rusty Wright
I'm now thinking that instead of using detachable=false, set it to true so that it can be easily updated. To create new unparented objects, use a constructor that takes a template object you got from the data store; Department fetchedDepartment = departmentDao.findById(id); Department

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-05 Thread bryce cottam
here's a really good talk about how objects are mapped into the BigTable datastore and how relationships are actually represented in the system: http://sites.google.com/site/io/under-the-covers-of-the-google-app-engine-datastore this sort of highlites how relationships actually work in BigTable

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-04 Thread datanucleus
Why is BookFK trying to use Datastore Identity ? (as the message says) identityType=IdentityType.APPLICATION would be recommended --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-04 Thread James H
BookFk is an embedded class intended to be used by entities like Chapter and others. It is NOT intended to be a standalone entity or have a Primary Key. So, when I try your fix I get the following compile error: SEVERE: Class struts2.example4.BookFk has application-identity and no

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-04 Thread datanucleus
BookFk is an embedded class intended to be used by entities like Chapter and others. Needs a PK either way. Pick a field, any field. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-04 Thread datanucleus
Needs a PK either way. Pick a field, any field. Or just set embeddedOnly as true ... if you really never want to persist one of those in its own right --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-04 Thread James H
Datanucleus, both suggestions worked but I like the embeddedOnly best in order to avoid a dummy key on every FK class! Bryce, I no longer get the error above...I just added embeddedOnly=true to the PersistanceCapable tag in BookFk class. You're right, I could use the collection technique on the

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-04 Thread James H
Rusty, Thanks for the code sample! How do you decide when to use key type of Key vs String? On Nov 4, 1:45 pm, James H james.hollier...@gmail.com wrote: Datanucleus, both suggestions worked but I like the embeddedOnly best in order to avoid a dummy key on every FK class! Bryce, I no longer

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-04 Thread Rusty Wright
Thinking out loud here: When you use that encoded string format you can use it wherever you'd use Key. The apparent advantage of using the encoded string format is that your dto isn't exposing GAE's Key. With the encoded string your service layer can be oblivious about GAE's Key, without

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-03 Thread bryce cottam
Sounds good James. The owned relationship between Book and Chapter is just defined by the fact that Book has a collection of Chapter as a member variable. If the relationship is bi-directional (i.e. Chapter has a Book as a member variable) then you use the mappedBy field in the @Persistent

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-03 Thread James H
Ok Bryce...I'm back. Going to test with your ideas now. In my case, I tend to avoid generic column names like id in favor of bookId and chapterId so I should not have any naming conflicts (at least rarely). Also, my FK embedded classes should not have any collections though I have a feeling

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-03 Thread James H
Consider this test case. A Person belongs to 1 or more Institutions so there's 2 ways you would want to query this. Query #1: Given a particular Person then which Institutions does he belong to? Query #2: Given a particular Institution then which Persons are members? Assume entity Person and

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-03 Thread Rusty Wright
I don't know if this will help, but I finally figured out how to do parent queries using the parent's primary key. At the moment I don't see what advantage there is if you're storing a reference to the parent object in the child and using mappedBy in the parent, but here's what I have, in

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-11-03 Thread bryce cottam
Hi James, sorry for the delay, My design is currently similar to what you proposed. However, in your example, I'd probably make 2 classes: PersonFK and InstitutionFK.: public class PersonFK { private Key id; private String firstName; private String lastName; private String

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-09-07 Thread leszek
I'm not sure if your taking of the problem is correct. To my mind it runs: You have Company and Employee. Company has many Employees and Employee is working for one company. Normalized version looks like: class Company { @Persistent private String companyName; @Persistent private String

[appengine-java] Re: Master/Detail relations and redundant data handling

2009-09-07 Thread James H
Right, denormalization is promoted by the Max Ross video as in your 2nd case so from a software design perspective can the copy fields in Employee be contained in their own class and referenced from Employee in a fashion that allows JDO to still work such as: class CompanyFK { // copy of