It sholdn't be cumbersome at all. Use the same key identifier for the tweets as for the Read entity, then do a batch get with those keys. Based on my numbers I'd say latency for 50 keys will be from 10ms to 20ms. You'll get back a Map (if using Java - not sure for Python). If they key is in the map then that tweet has been read otherwise it is unread. With a map doing lookups is fast and easy.
On Sun, Jan 9, 2011 at 10:57 PM, nischalshetty <[email protected]>wrote: > @Stephen Wow! I'm grateful to you for taking time out to make things so > clear. From what I see, you're suggesting to have a different key that when > present indicates a tweet as 'Read'. > > You're right, there would be pagination so I'll be displaying say 50 tweets > per page. Now, I would fetch 50 tweets and then check if any of the tweets > have a key in the 'Read' table. Suppose it has, then my pagination would go > for a toss. I hope you're getting me? Pagination becomes cumbersome if I try > to match an entity's status in a different table :( > > -N > > -- > 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]<google-appengine%[email protected]> > . > 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 [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.
