Unfortunately, the solution I proposed does not allow for adding additional filters when querying for all Campaigns with FundingOganization "ABC". If this is a requirement, you'll have to consider several options -- either doing the filtering in memory, which is reasonable if you only expect a handful of matched Campaigns, or including the criterion field in the table so you can query on it directly, which may muddle your schema.
Since App Engine's datastore doesn't support joins, most data models won't be completely normalized, which probably feels strange if you're coming from the RDBMS mindset. But storage is cheap and you can usually ignore the added redundancy if the data fields in question are not expected to change often. - Jason On Mon, Nov 2, 2009 at 3:27 PM, Hans <[email protected]> wrote: > > thanks Jason - I'll need to think more about how this would work in my > case. > > It sounds like I'll be able to query that new kind (return all the > Campaign keys for a FundingOrganization of "ABC") to get a collection > of keys. But then if I wanted to extract only the entities from that > result that meet certain criteria (Campaign.Duration > 30) , I'll need > to do that outside of the query language. > > I'm sure my questions reflect a newness to OOD. I do appreciate your > response. > > Hans > > On Nov 2, 3:27 pm, "Jason (Google)" <[email protected]> wrote: > > Hi Hans. Aside from the article on modeling entity relationships and the > JDO > > ... > > > > > It sounds like you want to add a new kind (as opposed to a new property > for > > an existing kind) and establish a relationship with this new kind > > (FundingOrganization) and an existing kind (Campaign). For many-to-many > > relationships such as this, one approach you can take is similar to what > you > > might do for an RDBMS schema: introduce a new table (kind) to model the > > relationship between FundingOrganization and Campaign entities. This > third > > kind would have only two properties, one storing a FundingOrganization > Key > > and the other a Campaign Key, then you can use it to query for all > > FundingOrganization entities associated with a given Campaign and vice > > versa. This approach doesn't require you to modify your Campaign kind at > > all, so you don't necessarily need to make it aware of the > > FundingOrganization kind, which was one of your requirements. > > > > Let me know if this answers your question or if you have any other > > questions. > > > > - Jason > > > > On Thu, Oct 29, 2009 at 1:55 PM, Hans <[email protected]> wrote: > > > > > Hoping someone might help me with a somewhat OT question. > > > > > I developed an object model for a GAE/J application that worked fairly > > ... > > > > Can someone point this rookie to intro material/URLs for building and > > > refactoring designs that lend themselves to these type of changes? I'm > > > looking for info on adaptable design, especially when you're using a > > > datastore and not using a RDBMS, junction tables, etc. > > > > > thanks, > > > Hans > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
