如何处理用户在谷歌应用程序引擎中更改查询参数
我有一个列表网站，其中的模型具有许多属性，我想在其中使用过滤器。我想使用内存缓存和游标进行查询，例如：
results=Model.all().filter("x =", a).filter("y =",b).with_cursor(cursor).fetch(20).
当用户更改过滤条件时，我应该如何处理游标和分页，例如
from `x=a to x=c`?
我应该存储具有 key = 查询字符串的游标吗？但是查询字符串会随着页码而变化:(。我想我需要解析查询字符串，删除页码并将其用作光标的键。我应该这样做吗？
I have a listing site having a model with many properties on which I would like to use filters. I would like to use memcache and cursor for querying, e.g:
results=Model.all().filter("x =", a).filter("y =",b).with_cursor(cursor).fetch(20).
How should I handle cursor and pagination, when the user change the filter criteria, e.g.
from `x=a to x=c`?
Should I store cursor having key = query string? But then the query string changes with page numbers :( . I guess i will need to parse query string, remove page numbers and use that as a key for cursor. Is that how I should do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以对当前过滤器进行“散列”，并将其传递给视图。它可以作为隐藏字段存储在那里，例如
在第二个请求时，您将检查当前过滤器的哈希值等于作为参数传递。
“哈希”可能是过滤器参数的 md5，或者只是将它们连接起来。
You can make an "hash" of your current filter, and pass it to view. That can be stores there as an hidden field, like
<input type="hidden" name="prev_query" value="{{query_hash}}"/>On second request you'll check that current filter's hash equals to passed as parameter.
'Hash' maybe md5 of your filter params, or just join concatenation of them.
将光标想象成一个书签，在结果集中保存位置。游标特定于它们所针对的查询。您不能对两个不同的查询使用相同的游标 - 这类似于期望一本书中的书签来显示您在另一本书中的阅读进度。
如果您想将游标存储在其他地方，则需要通过过滤条件对它们进行键控，以便您可以查找合适的游标。不过，Memcache 是一个糟糕的选择，因为元素可能随时被驱逐。为什么不直接将光标作为“下一页”URL 的一部分呢？
Think of a cursor like a bookmark, holding place in a result set. Cursors are specific to the query they are for. You can't use the same cursor for two different queries - that would be akin to expecting a bookmark from one book to show you how far through you are in another.
If you want to store cursors elsewhere, you'll need to key them by the filter criteria so you can look up the appropriate one. Memcache is a poor choice, though, as elements may be evicted at any time. Why not just make the cursor part of the 'next page' URL?