小编pat*_*atb的帖子

默认情况下,Flask使用volatile会话,这意味着会话cookie设置为在浏览器关闭时过期.为了使用永久会话,这将使用具有已定义的到期日期的cookie,应该设置session.permanent = True,如本问题中所述.,将根据以下内容设置到期日期config['PERMANENT_SESSION_LIFETIME'].

我很惊讶会话生存期在配置文件中定义,但是无法通过配置请求使用永久会话,例如a config['USE_PERMANENT_SESSION'] = True.但就是这样吧.

我的问题是:如果你确实想要永久性会议,那么定义它们的最佳位置是什么？它是否@app.before_request在上述问题中提出的功能中？但是这意味着每次请求都会重新设置它？似乎一旦确定,session.permanent直到会议结束时仍然如此.

永久会话通常在登录后使用,因此请求处理时最好的地方是处理login_user()？那么对所有匿名页面使用易失性会话cookie的最佳策略是什么,并通过session.permanent = True登录切换到永久会话？

人们可能希望根据它是普通的sessioncookie还是remember_mecookie 来设置不同的生命周期.实现这一目标的最佳方法是什么？

我习惯于定期备份和恢复我的NDB数据存储区,通常会恢复到不同的"项目",我将测试新版本的应用程序.到目前为止,它运作良好.

现在,Ndb恢复操作以系统方式失败,并在日志中跟踪:

Traceback (most recent call last):
  File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/_internal/mapreduce/handlers.py", line 526, in handle
    ctx.flush()
  File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/_internal/mapreduce/context.py", line 455, in flush
    pool.flush()
  File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/ext/datastore_admin/utils.py", line 695, in flush
    datastore._GetConnection()._reserve_keys(self.keys)
  File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/datastore/datastore_rpc.py", line 2170, in _reserve_keys
    self._async_reserve_keys(None, keys).get_result()
  File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/datastore/datastore_rpc.py", line 921, in get_result
    results = self.__rpcs[0].get_result()
  File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/api/apiproxy_stub_map.py", line 613, in get_result
    return self.__get_result_hook(self)
  File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/datastore/datastore_rpc.py", line 2211, in __reserve_keys_hook
    self.check_rpc_success(rpc)
  File "/base/data/home/runtimes/python27/python27_lib/versions/1/google/appengine/datastore/datastore_rpc.py", line 1371, in check_rpc_success
    raise _ToDatastoreError(err)
InternalError: Unexpected error contacting datastore (2016-11-19T18:01:37+00:00).

任何线索？我可能错过了一些东西,但是我发誓,与上周这种恢复工作正常的情况相比,没有任何改变.

为了防止我的最新备份出现问题,我尝试恢复旧备份,该备份已成功恢复了几次.恢复时出现相同的InternalError.包括一个全新的GAE项目.

经过多次(很多次)尝试,我发现同样的实体总会发生'意外错误'.整个备份/恢复涉及大约30种不同的类型,其中5种因所述错误而失败.其中,在某些情况下,有些实体已经恢复,但并非全部,在其他情况下,没有实体已经恢复.这就像某些特定实体可能对异常负责.但是,再一次,这也适用于过去曾有效的旧备份.

与Ndb备份和还原相关的问题很少(而且答案仍然较少).Ndb应用程序不使用备份吗？

在Flask我们最近升级Werkzeug到 1.0.1的应用程序中（因此我们可以在 cookie 上设置相同的站点），这强制了一些依赖项，其中Flask-BabelEx==0.9.4.

在这次升级之后，转义 %（百分号）的处理方式发生了非常令人不安的变化。凡gettext('foo %%')用于返回*"foo %"*，现在的回报*"foo %%"*，换句话说，％符号的逃逸似乎无法处理。我想，好吧，有点向上不兼容，我们只需要替换babel 字符串中的所有%%by %（在参考语言以及所有翻译中，所以这已经很重要了）。

但这并不是故事的结束，因为对于Jinja2 模板中使用的所有 babel 字符串，例如{{ _("This is a percent sign: %") }}，%仍然处理标志的转义，因此这仍然需要 {{ _("This is a percent sign: %%") }}. 那么我们是否必须%根据使用位置来处理转义和未转义的 babel 字符串？是否有某种设置可以缓解这种逃避问题。

我点击这个结果不能设置两次运行时错误GAE Ndb异步查询在做ndb.Future.wait_all(futures)一堆异步查询时.

像这样的东西:

futures = []
for item in items:
    item._future_get = MyEntity.query(...).get_async()
    futures.append(item._future_get)

ndb.Future.wait_all(futures)
# ...

它失败了wait_allwith with result无法设置两次

SO上没有提到此错误消息.谷歌在2011年有2-3次提及它,并没有明确的解释.

更多信息:

items是前一次获取的ndb实体.但它们在这里并不重要(至少我认为),因为查询是在MyEntity上执行的.我习惯以这种方式将期货附加到它们所涉及的对象上,因此当所有已完成时更容易理清.

堆栈跟踪:

  File "/home/my_project/app/main/admin/my_module.py", line 166, in admin_base_cleanup_details ndb.Future.wait_all(futures)
  File "/usr/lib/python2.7/google_appengine/google/appengine/ext/ndb/tasklets.py", line 350, in wait_all ev.run1()
  File "/usr/lib/python2.7/google_appengine/google/appengine/ext/ndb/eventloop.py", line 235, in run1 delay = self.run0()
  File "/usr/lib/python2.7/google_appengine/google/appengine/ext/ndb/eventloop.py", line 197, in run0 callback(*args, **kwds)
INFO     2016-04-26 08:40:04,152 module.py:808] default: "GET /admin/cleanup/details?mode=status HTTP/1.1" 500 -
  File "/usr/lib/python2.7/google_appengine/google/appengine/ext/ndb/tasklets.py", line 475, in _on_future_completion self._help_tasklet_along(ns, ds_conn, gen, …

Google Cloud 拥有强大的跟踪工具，用于分析请求和 RPC 的延迟。但它似乎只是选择了一些它认为值得跟踪的请求。有时这已经足够了，您只需浏览现有的跟踪即可。但是，如果您正在致力于性能增强，您希望立即跟踪特定查询，您不想等到它被认为有趣的时候。

问题是

• 哪些规则会影响决定跟踪哪些查询？

• 有没有办法要求捕获给定 URI 的跟踪？

是从开发人员控制台中，还是从我们的应用程序中调用一些 API？或者通过一些 app.yaml 配置？或者我们是否必须等待并祈祷伟大的算法来选择我们的请求？