Actually, I'm only going primarily by what Max Ross talked about in his JDO Persistence video at the I/O conference...
On Aug 15, 7:36 pm, objectuser <[email protected]> wrote: > You're obviously beyond my understanding then. > > On Aug 15, 6:25 pm, James H <[email protected]> wrote: > > > > > Thanks, I've been thru those very docs and they are too basic and do > > NOT contain most of the real world scenarios such as I'm speaking of. > > For example, if you listen to the Ross I/O video on Persistence he > > talks about the FK technique where you purposefully include additional > > fields from your Master record in with the Foreign record so that you > > do NOT have to query the Master when querying the Foreign rows...like > > you say, there are NO joins. The Audit fields I sited above are an > > even more basic illustration of the case, every Entity needs them so > > why cut/paste this field/code set across 100 Entity when you can let > > OO do the work... > > > The closest concept the docs you sited references are the Embedded > > Classes which only apply to 1 Entity...so they are quite useless from > > a OO perspective. Matter of fact, even this includes a naming hack to > > serve its purpose of reuse. My hunch is what I need is NOT supported > > and if it was supported, this Embedded hack would be deprecated. > > > The next closest example from your link would be where the Employee > > contains a field ContactInfo, but that does NOT apply here since it is > > for the case where ContactInfo is a separate Entity. > > > I thought the concept would be obvious, but I will gladly post some > > code to help illustrate my problem. This question arose from design > > talks, so the code is lagging behind a bit. > > > J > > > On Aug 15, 3:12 pm, objectuser <[email protected]> wrote: > > > > I really think you should read through the google documentation. It's > > > good stuff and can get you started with the concepts. I go back to it > > > over and over again because this stuff is very different for me. > > > Here's the link to the datastore docs, but there is great stuff under > > > the Articles section as well: > > > >http://code.google.com/appengine/docs/java/datastore/ > > > > You can have keys pointing to other entities and that's certainly an > > > important practice in GAE. In your first example, Address can contain > > > a key (or a collection of keys) to Person. So that's available to you > > > and you can query on that. I don't really know what you're talking > > > about with the PersonFK thing ... > > > > I'm also happy to talk more about your models. But I'm not sure I get > > > them. :) Want to post a bit of code so everyone here can really get > > > what you're trying to do? > > > > On Aug 15, 2:04 pm, James H <[email protected]> wrote: > > > > > Ok, replace "minimize" with "eliminate" in the 2nd sentence...but the > > > > root of the problem is still the same. Can this JDO implementation > > > > handle 2 or more Entities each containing a field using the same FK > > > > Object as in my hypothetical (it would contain the actual key plus > > > > extra fields)? > > > > > I'd love to see an example of that, matter of fact that should be in > > > > the standard set of examples...take for example Audit fields like > > > > createdByUser, createdDate, modifiedByUser, and modifiedDate. These > > > > fields should be on every entity and if you can't create an object > > > > like DataAudit and either have it as part of the parent class or at > > > > least a field of type DataAudit that would persist properly then guess > > > > what...we have increased time/labor involved in developing/maintaining > > > > the app. Same applies to this FK scenario. > > > > > If you know of an example, please shoot me a link! > > > > > On Aug 15, 12:00 pm, objectuser <[email protected]> wrote: > > > > > > Man, you're missing a lot. Joins are in no way supported in GAE > > > > > so ... yeah, you really do have to minimize them. > > > > > > There are a ton of good discussions in the group about alternatives. > > > > > > On Aug 15, 11:57 am, James H <[email protected]> wrote: > > > > > > > Am I missing something? I hear the best practice regarding Joins is > > > > > > to minimize them by placing redundant data with the FK. So for > > > > > > example if I have an entity Person relating as 1-to-many with > > > > > > another > > > > > > entity Address, then instead of just a simple FK like > > > > > > Address.personId > > > > > > I am supposed to also include redundant fields like > > > > > > Address.lastName, > > > > > > Address.firstName and so on depending on how I display/report on > > > > > > Address data in the app. > > > > > > > The problem is if I have 10 such relations with Person (1-to-1 or > > > > > > 1-to- > > > > > > many) and JDO does NOT allow me to declare a object we'll call > > > > > > PersonFK containing these fields (personId, lastName, firstName, > > > > > > etc), > > > > > > then we quickly have a code maintenance nightmare for our app since > > > > > > any significant app can have 100's of FKs to manage and all these > > > > > > fields will NOT be coded in an OO sense. > > > > > > > So in my example, if I have to add a redundant field for Person FKs > > > > > > or > > > > > > change behavior of an existing one, then I have at least 10 > > > > > > touchpoints where good OO design mandates I should only have 1 > > > > > > touchpoint. > > > > > > > Is this true or have I overlooked a feature in GAE JDO > > > > > > implementation?- Hide quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~----------~----~----~----~------~----~------~--~---
