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 [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?hl=en.
