我对Django的paginator模块如何工作以及如何优化它有疑问。我从互联网上的不同API获得的信息中列出了大约300个项目。我正在使用Django的paginator模块来显示我的访问者列表，一次显示10个项目。分页不像我想要的那样有效。看起来分页器必须获取所有300个项目，然后再拔出每次页面更改时需要显示的10个项目。例如，如果有30个页面，那么转到第2页需要我的网站再次查询API，将所有信息放入列表中，然后访问访问者浏览器请求的10个。我不想继续查询API以获取与每页翻页相同的信息。
现在，我的视图有一个查看get请求的函数，并根据查询查询API以获取信息。然后它将所有信息放入列表并将其传递到模板文件中。因此，只要有人翻页，此函数就会一直加载，从而导致再次查询API。
我该如何解决这个问题？
感谢您的帮助。
答案 0 :(得分：1)
在这种情况下，分页器需要完整列表才能完成其工作。
我的建议是定期更新供稿缓存，然后使用该缓存作为paginator模块的输入。对每个请求执行密集或长度任务总是一个坏主意。如果不是用户将体验到的页面加载时间，请考虑服务器的攻击漏洞。
您可能需要查看Django's low level cache API，这样您就可以将Feed结果存储在密钥下的全局可访问位置，以后您可以使用该密钥检索每个页面请求的缓存和分页。
答案 1 :(得分：0)
在选择行之前，ORM不会加载数据：
query_results = Foo(id=1) # No sql executed yet, just stored.
foo = query_results[0] # now it fires
或
for foo in query_results:
foo.bar() # sql fires
如果您使用的是在初始化时加载结果的自定义数据源，则分页将无法按预期工作，因为所有Feed都将立即获取。您可能希望将__getitem__或__iter__子类化以进行实际提取。然后它将与Django期望加载结果的方式一致。
分页需要知道有多少结果可以用来做像has_next（）这样的事情。在sql中，获得带有索引的count(*)通常很便宜。所以你也想知道会有多少结果（或者只是估计它是否过于昂贵而无法确切知道）。