--
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-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
In my app I have a an Entity group that stores user activity data - like a high level application log of user activity. This is the Entity Group that I expect to grow the fastest over time, and I have decided to keep only the last 3 months of "user activity" data to avoid indefinite datastore growth. Regarding how to keep this "3 month moving window", the obvious answer was - run a cron job daily that deletes entities older than 3 months, with some upper bound on number of deletes per day. However, a better solution comes to mind, and I'm wondering if someone can comment on whether it is indeed better:When I need to create a new User Activity entity, I should first search for an entity that is 3+ months old. If I find one, I'll "overwrite" it with the new user activity. This costs me one read and one write operations (and two more writes because there are two indexes associates with this entity kind). That's a total of 1 read and 3 writes with the new solution. In my current solution, I only have 3 writes and no reads, but 3 months later this entity will have to be deleted, which will incur an additional read and 3 writes (one for the entity itself and 2 for the two indexes). So, my theory is that my current solution has a total of 1 read + 6 writes, and my new solution saves me 3 writes. Anything wrong with this theory? Oh and also, I save the CPU time too because I don't need to run a cron job every day.