Ok, so if we have a single entity named Membership and a property could be their email domain suffix like Membership.domainSuffix=.com, .net, .uk, etc right? And querying on this property would auto-create an Index on domainSuffix. How would this alone help GAE to distribute the data such that .uk member data is likely to be located on servers in the UK and so on?
"distributing CRUD operations for you"...what is actually distributed here Ikai? Do you mean the "processing" is distributed (ie the use of app servers) or the data partitions are distributed near their originating Users within google infrastructure. Virtually every google app has this same problem to solve and if there is a Best Practice offered then as a whole the entire google infrastructure will benefit from efficient implementations of this most common requirement. Please advise. On Nov 10, 5:41 pm, "Ikai L (Google)" <ika...@google.com> wrote: > James, > > The way I would probably do this would be to create an enum in the scope of > the Membership class representing a region and store it as an indexed > property. The App Engine data store will take care of distributing the CRUD > operations of related data for you. You probably won't get much bang for > your buck by creating different entities. By maintaining a single Membership > entity, you'll be able to more easily reuse related class. At its most low > level, the App Engine datastore is simply a distributed, type agnostic > key-value store. App Engine recognizes entities by creating an index for all > of your application's Entities, and indexes are created for each property by > default. I would recommend creating a Data Access layer and doing the > segmentation there. > > On Tue, Nov 10, 2009 at 1:48 PM, James H <james.hollier...@gmail.com> wrote: > > > Is there a best practice entity design for storing Membership data > > that targets a global market? Ideally, the Membership data is > > partitioned geographically since a Membership in the U.S. is > > independent of one in the U.K. and elsewhere, for example. The motive > > is that operations (searches, inserts, updates, deletes) on U.S. data > > need NOT involve data from the U.K. and elsewhere. Can GAE > > transparently provide this based on the design of a single Membership > > Entity or do you have to create separate Entities for each region in > > your design such as MembershipUS, MembershipUK, etc? > > -- > Ikai Lan > Developer Programs Engineer, Google App Engine --~--~---------~--~----~------------~-------~--~----~ 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-java@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 -~----------~----~----~----~------~----~------~--~---
