互联云天

在实现YTBlog分页功能的时候，碰到几个datastore相关的问题。第一个问题，要做分页得知道所有Blog的数目，有几种方法：

1、创建一个Query或者GqlQuery对象，调用其count()方法。但这个方法有很大的局限性，首先限制最多只能返回1000，而且其执行时间随着结果的数目增加而增加，官方推荐只有在结果集很小的时候才使用。而这里要取Blog数目只能忍受常量时间，这个功能还会在首页用到，所以不能采纳。

2、 变通一下，先解决最大只能返回1000的问题，可以调用fetch()方法，如果返回的数目只有1000个，则继续递归调用，直至返回数目小于1000，把所有的数目加起来则是Blog的数目。

3、官方文档中讲Query是iterable的，那么就用Python中iterable的方法来取数目。不过估计这个方法直接执行的效率比不上方法2。

再说效率的问题，上面三种方案可以用memcache解决效率问题，把算出来的结果存在memcache中，当添加或者删除Blog的时候也主动更新memcache。但是代码实现起来就不是那么简单直接了，因为考虑到会碰到组合各种条件查询的情况，要对各种查询条件都维护一个memcache中的 Blog数目是很麻烦的，特别是添加或者删除Blog的时候。

4、自己维护一个Blog数目meta data存在datastore中。也可以解决数目和效率的问题。当然，也会碰到组合查询条件的问题，有个简单的解决方法么，就是限制分页的应用场景，也就是限制查询条件的组合。

有 了准确的Blog数目，页面上的分页就可以创建出来了。但第二个问题随之出现，假设每页显示10个Blog，需要直接跳至第101页，那么需要地用 Query的fetch()方法，其中limit=10，offset=1000。官方文档中又讲了，fetch方法的执行效率是随 limit+offset而线性增长的，而不仅仅是limit，也就是这里的复杂度得用1010来衡量。效率问题仍然存在。

上面两个问题在关系型数据库里应该也是一样存在的吧？不知道别人实现分页是怎么做的。

这里我对count()和fetch()的实现有些疑问。Google为什么会限制返回查询结果的数目为1000呢。实际上当用 limit=10，offset=1000的条件fetch的时候，datastore是返回1010个结果给fetch()的，只是fetch()把前 面1000条过滤掉了（参见这里关于fetch方法的说明）。这么设计的初衷是什么？

YTBlog里面具体的是这样实现的：只在界面上提供了"上一页"和"下一页"功能，这样就避开了第一个问题。实现代码在这里，BlogController的子类调用get_page_objects即可获得分页信息，调用代码在这里。