Ah yeah, deleting in bulk in a cron job or ongoing task would definitely
work. I dunno why that didn't dawn on me earlier.  Thanks Nick!

On Thu, Jan 14, 2010 at 12:21 AM, Nick Johnson (Google) <
nick.john...@google.com> wrote:

> Hi,
>
> On Thu, Jan 14, 2010 at 6:07 AM, Patrick Twohig <patr...@namazustudios.com
> > wrote:
>
>> Perhaps I didn't explain my use case entirely well enough.  Basically it's
>> a leaderboard (high scores table) for an online game.  After thinking a
>> little more GAEly I came up with the following solution.  I was curious if
>> anybody had any comments or critiques for my approach.
>>
>> Create a "WeeklyLeaderboardEntry" (or similarly named kind).  That
>> basically contains the player's score and the player's unique name.  And use
>> it as follows:
>>
>> Make some code that establishes a sequence of weeks.  Let's say the number
>> of weeks since the Epoch.  For instance if it's January 3, 1970, the current
>> week is 0.  If it's January 8, 1970 it's week 1 and so on.
>>
>> When player finishes game:
>> 1) Look for WeeklyLeaderboardEntry with the current.  If it exists, skip
>> to step 4. (Maybe name the entitye PlayerName-Sequence).
>> 2) Create "WeeklyLeaderboardEntry" for the current week.
>> 3) Queue the entity to be deleted a week from now.
>> 4) Set the player's current high score to that entity.
>> 5) Persist object to be updated later in case the player plays another
>> game
>>
>> When displaying the leaderboard:
>> 1) Query for "WeeklyLeaderboardEntries"
>> 2) Filter out ones not pertaining to the current week
>> 3) Sort highest score to lowest
>>
>> This way the following holds true:
>>
>>    - When the user is updating his/her high score he/she is only working
>>    a single entity.  I never need to do bulk updates in a cron job or 
>> anything.
>>    - I don't need to write a cron job to go through a whole mess of
>>    leaderboard entities trying to reset the counter for everbody at once.
>>    - When the week rolls over it appears to happen atomically because I
>>    just restrict the query to the current week.  There may be stale entry
>>    objects but those will get deleted at he app engine's leisure.
>>
>> My only questions/concerns:
>>
>>    - Is it okay to queue something to be deleted after a week? Will the
>>    task queue accept a timeout for that length of time?
>>
>>
> Timeouts can be for up to a month. Queueing a task per entry is somewhat
> inefficient, however - you'd be better running a series of tasks at the end
> of the week that query for old entries and delete them in batches.
>
>>
>>    -
>>    - Will the task queue keep up with clearing out stale entities as fast
>>    as they can be created
>>
>>
> That depends on the rate of creation. Batch operations will allow you to
> sustain a much higher rate with fewer resources.
>
> -Nick Johnson
>
>
>>
>>    - ?
>>
>>
>>
>> On Wed, Jan 13, 2010 at 7:28 PM, Eric Ka Ka Ng <ngk...@gmail.com> wrote:
>>
>>> how about batch update using db.put()?
>>>
>>> following is extracted from
>>>
>>> http://googleappengine.blogspot.com/2009/06/10-things-you-probably-didnt-know-about.html
>>>
>>>
>>> For example, take a look at this common pattern:
>>>
>>> for entity in MyModel.all().filter("color =",
>>>    old_favorite).fetch(100):
>>>  entity.color = new_favorite
>>>  entity.put()
>>>
>>>
>>> Doing the update this way requires one datastore round trip for the
>>> query, plus one additional round trip for each updated entity - for a
>>> total of up to 101 round trips! In comparison, take a look at this
>>> example:
>>>
>>> updated = []
>>> for entity in MyModel.all().filter("color =",
>>>    old_favorite).fetch(100):
>>>  entity.color = new_favorite
>>>  updated.append(entity)
>>> db.put(updated)
>>>
>>> By adding two lines, we've reduced the number of round trips required
>>> from 101 to just 2!
>>>
>>>
>>>
>>> - eric
>>>
>>>
>>> 2010/1/14 Patrick Twohig <patr...@namazustudios.com>:
>>> > So I'm looking at trying to reset large amounts of data en masse.  Say
>>> I
>>> > want to reset a counter on every account each week, how would I go
>>> about
>>> > implementing something like that?  Would I have to go through each
>>> object,
>>> > update it, and store it?  If that's the case, how do I go about doing
>>> so
>>> > without killing my quota or running up my usage extremely high?
>>> >
>>> > Thanks,
>>> > Patrick.
>>> >
>>> > --
>>> > 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-appengine@googlegroups.com
>>> .
>>> > To unsubscribe from this group, send email to
>>> > google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com>
>>> .
>>> > 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 google-appeng...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/google-appengine?hl=en.
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Patrick H. Twohig.
>>
>> Namazu Studios
>> P.O. Box 34161
>> San Diego, CA 92163-4161
>>
>> Office: 619.862.2890 x100
>> Cell: 619.453.5075
>> Twitter: @svm_invictvs
>> IRC: svm_invic...@irc.freenode.net ##java, #android-dev, #iphonedev,
>> #appengine
>>
>> http://www.namazustudios.com/
>>
>> This communication, and any attachments, shall be considered confidential
>> and proprietary information of Namazu Studios LLC.  This message, and
>> attachments, are intended for the listed recipients only.  If you are not
>> one of the intended recipients, please destroy all copies of this
>> communication.
>>
>> --
>> 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-appeng...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>>
>
>
> --
> Nick Johnson, Developer Programs Engineer, App Engine
> Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number:
> 368047
>
> --
> 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-appeng...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
>


-- 
Patrick H. Twohig.

Namazu Studios
P.O. Box 34161
San Diego, CA 92163-4161

Office: 619.862.2890 x100
Cell: 619.453.5075
Twitter: @svm_invictvs
IRC: svm_invic...@irc.freenode.net ##java, #android-dev, #iphonedev,
#appengine

http://www.namazustudios.com/

This communication, and any attachments, shall be considered confidential
and proprietary information of Namazu Studios LLC.  This message, and
attachments, are intended for the listed recipients only.  If you are not
one of the intended recipients, please destroy all copies of this
communication.
--
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-appeng...@googlegroups.com.
To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

Reply via email to