【问题标题】:App Engine Dev Server datastore not updating fast enough?App Engine 开发服务器数据存储更新速度不够快?
【发布时间】:2013-09-05 00:06:24
【问题描述】:

问题:数据存储更新太慢 - 提交创建实体的表单后,需要在显示数据存储中实体的结果页面上点击重新加载。

预期行为:实体应该出现在查询中,因为我正在将 NDB 用于我的数据存储区,它会自动缓存内容。

问题重现步骤

  1. 在适用于 Mac 的 GoogleAppEngineLauncher 1.8.3(我的操作系统版本是 10.8.4)中创建一个默认项目并将下面的代码粘贴到“main.py”中
  2. 运行项目并访问根 URL。
  3. 在表单中输入一个数字并点击提交。
  4. 您将看到文本“这是实体列表:...结束列表。”
  5. 在浏览器上点击重新加载。
  6. 现在您将看到文本“这里是实体列表:[您输入的编号] ...结束列表。”

预期行为说明

由于 NDB 自动使用 memcache,因此不应发生第 4 步和第 5 步。单击表单上的提交后,您输入的数字应该会显示出来。我在常规的 appengine DB 中也观察到了这种行为,我知道我可以使用 memcache 解决它。

下面是一些代码,您可以将它们放入由 AppEngineLauncher 创建的默认 main.py 中,以复制此问题:

import webapp2
from google.appengine.ext import ndb

class SmallModel(ndb.Model):
    n = ndb.IntegerProperty(required=True)
    stamp = ndb.DateTimeProperty(auto_now_add=True)

class MainHandler(webapp2.RequestHandler):
    def get(self):
        self.response.write('Hello world. Simple form. <form method="post"><input name="n" type="number"><input type="submit"></form>')
    def post(self):
        entity = SmallModel(n=int(self.request.get('n')))
        entity.put()
        self.redirect('/list')

class List(webapp2.RequestHandler):
    def get(self):
        self.response.out.write("here's a list of entities:")
        entities = SmallModel.query()
        for entity in entities.iter():
            self.response.out.write(" %s " % entity.n)
        self.response.out.write("...end list.")

app = webapp2.WSGIApplication([
    ('/', MainHandler),
    ('/list',List)
], debug=True)

任何帮助/建议?先感谢您!我已经能够在我测试的两个浏览器中重现这个问题——Chrome 和 Safari。

【问题讨论】:

    标签: python google-app-engine google-cloud-datastore


    【解决方案1】:

    我遇到了类似的问题。感谢您的解决方案。 顺便说一句,我认为 GAE 文档已与您原来的解决方案有所不同。

    对于这一行:

    entities = SmallModel.query(ancestor=parent_key())
    

    应该是:

    entities = SmallModel.ancestor(parent_key())
    

    【讨论】:

      【解决方案2】:

      我设法得到了我的预期行为,我的更新代码如下。我从具有我期望的行为的“留言簿”示例代码中得到了一个提示,并设置了一个父键。我还深入研究了 NDB 文档。设置父键可实现我期望的一致性,但将写入限制为每秒一次(我假设这意味着给定父键的所有子键,而不是给定模型的所有实体)。

      这是我为消除第 4 步和第 5 步所做的更改。我只是在新实体上设置了一个父键,并使用此父键进行祖先查询。 (当然,这是用于说明一点的极简代码,我对创建数字列表的模型没有真正的兴趣。;))

      import webapp2
      from google.appengine.ext import ndb
      
      def parent_key():
          return ndb.Key('My','Entities')
      
      class SmallModel(ndb.Model):
          n = ndb.IntegerProperty(required=True)
          stamp = ndb.DateTimeProperty(auto_now_add=True)
      
      class MainHandler(webapp2.RequestHandler):
          def get(self):
              self.response.write('Hello world. Simple form. <form method="post"><input name="n" type="number"><input type="submit"></form>')
          def post(self):
              entity = SmallModel(parent=parent_key(),n=int(self.request.get('n')))
              entity.put()
              self.redirect('/list')
      
      class List(webapp2.RequestHandler):
          def get(self):
              self.response.out.write("here's a list:")
              entities = SmallModel.query(ancestor=parent_key())
              for entity in entities.iter():
                  self.response.out.write(" %s " % entity.n)
              self.response.out.write("...end list.")
      
      app = webapp2.WSGIApplication([
          ('/', MainHandler),
          ('/list',List)
      ], debug=True)
      

      感谢您的阅读和参与。

      【讨论】:

        【解决方案3】:

        这是最终一致性的行为。我不确定您要做什么,也许您可​​以更改数据建模,因此 fetch 始终保持高度一致。

        在您的数字列表示例中,您可以将它们存储在一个实体的 ListProperty 中,以便始终以高度一致的方式获取它

        【讨论】:

          【解决方案4】:

          ndb 非常明确,它不会在内存缓存中查找查询结果。只有 get() 从内存缓存中获取实体。

          特别是文档说 -

          查询不会在任何缓存中查找值。但是查询结果 如果缓存策略这样写,则写回上下文缓存 (但永远不会到 Memcache)。

          https://developers.google.com/appengine/docs/python/ndb/cache 上下文缓存部分。

          另请参阅关于相同 ndb 和 memcache 的这个 SO 问题,How automatic NDB caching works?

          您可能会在生产中发现同样的问题。这是由于现在在开发环境中模拟了最终的一致性。您需要使用 get 来确保一致性或处理查询结果的潜在延迟。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2017-01-02
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多