Why not simply have the reference in the Thing, pointing to the User? Then use the idiom: x = user.thing_set.fetch(1000) to get the User's Things? Update both the User and the Thing using a single db.put([thing, user])
johnP On Oct 9, 2:19 pm, Josh Heitzman <[EMAIL PROTECTED]> wrote: > I ran into a similar problem with the strategy game I'm working on. > The game world is divided up into areas and each area can have a more > then one player's troops in it at a time. I've modeled these with > three entities, player, area, and areaplayer. When a player has his > troops do something in an area it can potentially affect the area > state, the associated areaplayer states, and the associated player > states. If all of those things were in the same entity group that > would mean the entire game state would be in the same entity group > resulting in massive contention. Instead each player and their home > area is an entity group and each non-home area is an entity group. > The areaplayer is in the entity group with the area, which is the same > as the player for the case of the home area. > > So when a player orders troops to do something in their home area when > no other player has troops there, its no problem as the player, the > area, and the sole areaplayer are all in the same entity group so a > GAE DS transaction can be used. However, orders given to troops away > from home or at home other players have troops there have to make > updates to multiple entity groups. > > I'm dealing with this by via a reliable multi-entity group update > mechanism (no rollback, but will continue processing the update across > requests and server process instances) that I hope can be enhance into > true multi-entity group transactions if that can actually be done will > still staying under quotas. I'm getting close to deploying my > prototype with the reliable multi-entity group update mechanism, so I > can find out how I'm doing on quotas as it is. Then I'll know if > there is possibly create a cross-entity group transaction mechanism. > > I really think Google needs to provide cross-entity group transactions > though, as they'll be able to do it in native code, and thus faster > then we'll be able to do it in Python on at the app level. > > On Oct 9, 1:20 pm, David <[EMAIL PROTECTED]> wrote: > > > thanks for the replies. > > > as i mentioned in the question, the Thing will become a product and > > could be sold to another user at a later date. A list of keys is also > > what ive been using, as a referenece property in the Thing causes the > > blobs to pulled from the data store (they can be quite large, well > > less then a mb aye ;) ) when i want to list the users current things > > (by title). > > > i guess another way of looking at it is really the user is creating a > > new product. and then is trying to buy it. if the product is no longer > > wanted by anyone it can be deleted. > > > i was trying to work out a was to safly trasact on the money so the > > Thing never touches the datastore if there isnt enough cash. But this > > is a unuaul case, things will be sold between users more then created. > > > any thoughts? its all a learning process for me. > > > On Oct 9, 8:49 pm, Bill <[EMAIL PROTECTED]> wrote: > > > > > Have you seen: "Entity Groups, Ancestors and Paths" > > > > ?http://code.google.com/appengine/docs/datastore/keysandentitygroups.html > > > > Good point. If a Thing will never be used for another User (e.g., it's > > > not a product), you could make the Thing part of a User's entity group. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
