Ok. A trick I use is to use the key field to hold more than one piece of data so that I can get around some of the limitations of queries as well as get back info doing keys only queries and keeping down the number of the custom keys I have, so you could do something like the following: I suppose each of your users has some sort of user id and that the tweets have some sort of identifier, let's say User-ID and Tweet-ID. Also, I will assume the Tweet-ID you assign also relates to the time of the tweet, that is Tweet-ID 17 would always have a date/time before Tweet-ID 18 and Tweet-ID 18 would always be before Tweet-ID 19, etc. And that is how you are paging through your tweets. That is by date/time. If not then an additional piece of information of date/time would need to be factored in. I will now use the entity name *RS* standing for *ReadStatus* instead of *Read*. We want to keep entity names as short as possible because it is meaningless information (as far as we are considered not Google) that is added to the keys. So you could use as your key format the following: *User-ID:Tweet-ID*
Also, we would add one more property to the RS entity of type boolean and name it *R* (again keep names short) indicating whether or not the Tweet has been read (true) or unread (false). Now, if the user wants to paginate through all tweets then use the Tweet entity itself and use the RS entity and a keys only query to determine its read status. If the user wants to page through tweets that are yet unread then again do a keys only query (using a cursor to save position) on the RS entity and then do a get by keys on the Tweet entities. Do the same for tweets that have been read. Queries would look like * select __key__ from RS where R == FALSE* Another difference between what I suggested before is that you will need to add entries to the RS entity for both read and unread entities, but the upshot of this approach would be that when you do a Mark All As Read for 10000 tweets you don't have to actually query the 10000 tweets and pull those entities in to memory and then update them. You can just get the keys, then do a PUT (without a GET) to the RS entity safely overwriting any existing values since the only value is the boolean flag. I hope this helps you to think through and find a solution, Steve On Sun, Jan 9, 2011 at 11:27 PM, nischalshetty <[email protected]>wrote: > My bad. I forgot to mention, there would be an option where I show just the > 'unread' tweets to the user or just the 'read' tweets. When I show all > tweets, your example would work perfectly fine. But what about the other two > scenarios? Any pointers would help. I use GAE/J. > > -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.
