I'm adding a 'mark read' feature to my app, which then of course means I need to filter out read items when viewing. So I'm trying to design this to have the lowest possible cost and am considering 2 options:
1) Make keys meaningful enough (e.g. [userid]-[itemid]) that I can do a batch get for 100 keys, and the ones that return are the read items. Unfortunately AFAIK there is no way to do a key-only get so even if the entity has no properties (or just a handful) I still incur '1 Read' cost for each hit (and this may often be 100 out of 100). 2) Make keys meaningful enough, again, but store userid and itemid as properties as well. Use an IN query, returning keys only, passing the 100 itemids. But the question then is, do I get charged a separate '1 Read' for each value in the IN (since INs are split apart as separate queries), in addition to the '1 Small' for each hit/key returned? Also, how much faster does #2 perform since it returns keys only? Oh and I'm not too worried about difference in write costs since I think reads will outnumber writes by about a factor of 10. Thanks for taking a look! -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/1w4mkJfKS-cJ. 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.
