Options 2 or 3 sound like good choices. Option 1 will leave 'junk' lingering around your datastore cluttering stuff up. Any operation you might need to run over all child entities will (potentially) need to be aware of orphaned records. Just seems like the kind of thing that will bite you down the road.
With option 2 you need to do a bit more up front, but not much. Kick off a transactional 'deleted' task that analyzes the hierarchy and spawns any other needed tasks. That will let the delete handler return quick. Then the backend will clean itself up. Option 3 is very similar to option 2. The biggest benefit I see is that perhaps you can somehow batch delete operations more efficiently? I think you'll still wind up using the task queue to handle cascading deletes though, right? I guess you would basically pull the deleted entity markers, build some type of processing list and delete as much as you could before getting a timeout and repeat? Using task queues this could be probably be parallellized to be made more efficient. Not really sure my thoughts really add much. Currently In my code I use option 2 for a variety of things (updates and deletes). I just like it because it gets stuff done as close as possible to the user's action. Robert On Fri, Aug 27, 2010 at 09:15, Jeff Schwartz <jefftschwa...@gmail.com> wrote: > Hi all, > > I'm developing an application that has the following datastore models: > > StatusUpdate - members' distributed status > StatusUpdateLike - members can mark a StatusUpdate as liked > StatusUpdateLikeCounter - counter of # of members who like a StatusUpdate > DistributionIndex - has a list property of member ids used to syndicate > content to subscribed members > Comment - a comment made by a member about a StatusUpdate > CommentLike - members can mark a Comment as liked > CommentLikeCounter - counter of # of members who like a Comment > > A StatusUpdate can have many Comments but there is no entitygroup > relationship between them. > A StatusUpdate can have many DistributionIndexes and both form an enitty > group where StatusUpdate is the root of the hierarchy and > DistributionIndexes are the children. > A StatusUpdate can have many StatusUpdateLikes but there is no entitygroup > relationship between them. > A StatusUpdate can have many StatusUpdateLikesCounters (sharded) but there > is no entitygroup relationship between them. > A Comment can have many CommentLikes but there is no entitygroup > relationship between them. > A Comment can have many CommentLikeCounters (sharded) but there is no > entitygroup relationship between them. > > When a StatusUpdate is deleted by the member who created it I am thinking I > can approach 'clean up' in one of 2 ways & I would like your opinions on > both: > > 1) I can just delete the StatusUpdate and its child DistributionIndexes and > leave all the other entities in place in the datastore. This would not > impact the application because the StatusUpdate is the root of its logical > hierarchy and without it all the other entities are ignored. Depending on > the popularity of the application leaving these entities in place could > result in the datastore maintaining thousands of orphaned entities. > > 2) I can go through the logical hierarchy and cascade deletion. Depending on > the popularity of the application this could require the deletion of > thousands of records. Though everything would be done using keys and batch > deletes, deleting thousands of records couldn't be done in-process and would > require kicking of tasks to perform the cascading deletes. > > 3) I could use a combination of the above. When a member deletes a > StatusUpdate I could delete it and its associated DistributionIndexes and > create a new entity that would serve as a marker for the deleted > StatusUpdate. I could then schedule a task to kick off periodically that > would query for the marker entities. If found I could kick off tasks to do > the clean up out of process. > > The simplicity of approach #1 above is very attractive but I am concerned > about its impact on the size and growth/datastore, > > The complexity of approach #2 & #3 above concerns me because I would need to > use tasks (I haven't implemented tasks yet on app engine) & I don't know > what a good implementation would require. > > What do you think about this? Suggestions & comments welcomed. > > Jeff > > -- > 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-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
