what is paginator and has_key() added to cache in trunk
3 views
Skip to first unread message
Joe Bowman
Mar 5, 2009, 9:49:53 PM3/5/09
to appengine-utilities
I'm still not close to being ready for a release, working on
paginator. However one requirement for paginator was to add a has_key
method to cache, so if you need it, feel free to grab it from the
trunk.
What is paginator? A pagination class. I've got some pretty robust
requirements for the site I'm working on, so paginator will meet all
of the requirements below
- variable model attribute to sort on (defaults to __key__)
- variable amount of objects to grab per page
- grab the sort value for the previous and next pages
- result caching, in order to decrease load time/cpu on future views.
This includes indexing of the page next/prev values
- cache clearing, for page lists that can change (ie: item deletion,
or the values sorted on changing).
paginator will not support page numbers. You will need to build prev
# / next # links and paging will go through them.
paginator. However one requirement for paginator was to add a has_key
method to cache, so if you need it, feel free to grab it from the
trunk.
What is paginator? A pagination class. I've got some pretty robust
requirements for the site I'm working on, so paginator will meet all
of the requirements below
- variable model attribute to sort on (defaults to __key__)
- variable amount of objects to grab per page
- grab the sort value for the previous and next pages
- result caching, in order to decrease load time/cpu on future views.
This includes indexing of the page next/prev values
- cache clearing, for page lists that can change (ie: item deletion,
or the values sorted on changing).
paginator will not support page numbers. You will need to build prev
# / next # links and paging will go through them.
jonathan
Mar 17, 2009, 6:24:44 AM3/17/09
to appengine-utilities
Hey Joe, this paginator sounds very similar to my requirements that
you commented on here:
http://groups.google.com/group/google-appengine/browse_thread/thread/d57c07a99a83029f/d14cafd8d1b55d15?lnk=gst&q=memcache#d14cafd8d1b55d15
how far along are you with this? and what do you mean by "not
supporting page numbers"? Won't you need some way of indexing into the
cache collection? how will it be referenced? from a purely selfish
point of view, I think I would need page numbers, and it would be cool
if that were what you were doing.
j
you commented on here:
http://groups.google.com/group/google-appengine/browse_thread/thread/d57c07a99a83029f/d14cafd8d1b55d15?lnk=gst&q=memcache#d14cafd8d1b55d15
how far along are you with this? and what do you mean by "not
supporting page numbers"? Won't you need some way of indexing into the
cache collection? how will it be referenced? from a purely selfish
point of view, I think I would need page numbers, and it would be cool
if that were what you were doing.
j
Joe Bowman
Mar 17, 2009, 9:00:54 AM3/17/09
to appengine-utilities
I originally tried the page number route for one of the projects I was
working, and is why I ended up writing the paginator. My original
attempt was
pull 100 entities and cache those results
page through those 100 entities, allowing page numbers
What I found was that pulling 100 entities created for me what was
unacceptable load times. While the requests afterwards were acceptably
fast, pulling from cache, I didn't like the request that populated the
cache.
The extra complication for this project, is that the lists I'm
building are built on a scoring mechanism that means the order of the
results changes often.
paginator is currently in trunk, and has had some work but hasn't been
fully tested yet. I've gotten sidetracked with another project where
I'm not using the datastore much at all, so work isn't continuing on
paginator until I complete that. With my 4-6 hours of development
time, it may be a few weeks. However, the paginator in place should be
at least somewhat functional though I believe it currently lacks the
caching. I was using it for this other project to get around some
limitations in the youtube api, but the source release to do
asynchronous urlfetch calls is a better solution to reach my goal,
hence why I'm not chasing down completing paginator right now. When I
get back to my other project, paginator will become a priority again.
From the docstring of paginator
(NOTE: it actually returns key results, not items, I need to update
that in the docstring, just noticed that)
def get(cls, count=10, q_filters={}, search=None, start=None,
model=None, \
order='ASC', order_by='__key__'):
"""
get queries the database on model, starting with key, ordered
by
order. It receives count + 1 items, returning count and
setting a
next field to the count + 1 item key. It then reverses the
sort, and
grabs count objects, returning the last as a the previous.
Arguments:
count: The amount of entries to pull on query
q_filter: The filter value (optional)
search: Search is used for SearchableModel searches
start: The key to start the page from
model: The Model object to query against. This is
not a
string, it must be a Model derived object.
order: The order in which to pull the values.
order_by: The attribute to order results by. This
defaults to
__key__
Returns a dict:
{
'next': next_key,
'prev': prev_key,
'items': entities_pulled
working, and is why I ended up writing the paginator. My original
attempt was
pull 100 entities and cache those results
page through those 100 entities, allowing page numbers
What I found was that pulling 100 entities created for me what was
unacceptable load times. While the requests afterwards were acceptably
fast, pulling from cache, I didn't like the request that populated the
cache.
The extra complication for this project, is that the lists I'm
building are built on a scoring mechanism that means the order of the
results changes often.
paginator is currently in trunk, and has had some work but hasn't been
fully tested yet. I've gotten sidetracked with another project where
I'm not using the datastore much at all, so work isn't continuing on
paginator until I complete that. With my 4-6 hours of development
time, it may be a few weeks. However, the paginator in place should be
at least somewhat functional though I believe it currently lacks the
caching. I was using it for this other project to get around some
limitations in the youtube api, but the source release to do
asynchronous urlfetch calls is a better solution to reach my goal,
hence why I'm not chasing down completing paginator right now. When I
get back to my other project, paginator will become a priority again.
From the docstring of paginator
(NOTE: it actually returns key results, not items, I need to update
that in the docstring, just noticed that)
def get(cls, count=10, q_filters={}, search=None, start=None,
model=None, \
order='ASC', order_by='__key__'):
"""
get queries the database on model, starting with key, ordered
by
order. It receives count + 1 items, returning count and
setting a
next field to the count + 1 item key. It then reverses the
sort, and
grabs count objects, returning the last as a the previous.
Arguments:
count: The amount of entries to pull on query
q_filter: The filter value (optional)
search: Search is used for SearchableModel searches
start: The key to start the page from
model: The Model object to query against. This is
not a
string, it must be a Model derived object.
order: The order in which to pull the values.
order_by: The attribute to order results by. This
defaults to
__key__
Returns a dict:
{
'next': next_key,
'prev': prev_key,
'items': entities_pulled
}
On Mar 17, 6:24 am, jonathan <jricket...@gmail.com> wrote:
> Hey Joe, this paginator sounds very similar to my requirements that
> you commented on here:http://groups.google.com/group/google-appengine/browse_thread/thread/...
On Mar 17, 6:24 am, jonathan <jricket...@gmail.com> wrote:
> Hey Joe, this paginator sounds very similar to my requirements that
Reply all
Reply to author
Forward
0 new messages