Google app engine 跨多个应用程序版本的数据转换

升级GAE应用程序时，升级数据模型的最佳方式是什么

应用程序的版本号允许分离多个版本，但这些应用程序版本使用相同的数据存储（根据）。那么，当我上传具有不同数据模型的应用程序版本时会发生什么情况（我在这里考虑python，但这个问题对于Java也应该有效）？我想，如果更改添加了一个可为null的字段和一些新类，那么现有模型就可以扩展而不会受到损害，这应该不会是一个问题。但是，万一数据模型的变化更加深刻，又该怎么办呢？如果现有数据与新数据模型不一致，我是否真的会丢失这些数据

---

目前我看到的唯一选择是将数据存储设置为维护只读模式，脱机转换数据并重新部署整个数据。

处理这种情况的方法很少，而且它们并不相互排斥：

• 对您的数据存储进行不间断的更改，并解决它造成的问题。在现有模型类中插入新字段、将字段从必填字段切换为可选字段、添加新模型等等——这些都不会破坏与任何现有实体的兼容性。但由于这些实体不会神奇地改变以符合新模型（请记住，数据存储是一个无模式的数据库），您可能需要一个部分支持旧模型的遗留代码。 例如，如果您添加了一个新字段，您将希望通过

  getattr（实体，“字段名称”，默认值）

  而不是

  entity.field\u name

  来访问它，这样就不会导致旧实体出现

  AttributeError

• 逐渐将实体转换为新格式。这很简单：如果您发现一个实体仍然使用旧模型，请进行适当的更改。在上面的示例中，您希望在添加新字段的情况下将实体放回：

  if not hasattr(entity, "field_name"):
      entity.field_name = default_value
      entity.put()
  val = entity.field_name # no getattr'ing needed now
  

  理想情况下，您的所有实体最终都将以这种方式进行处理，并且您将能够在某个时候删除转换代码。事实上，总会有一些剩余的东西需要手动转换——这让我们想到第三个选项

• 批量将实体转换为新格式。这背后的物流复杂性在很大程度上取决于要处理的实体的数量、站点的活动、可用于此过程的资源等。请注意，使用简单的MapReduce可能不是最好的主意，尤其是如果您使用上述渐进转换技术。这是因为MapReduce处理所有给定类型的实体（获取它们），而可能只有一小部分需要这样做。因此，手工编写转换代码，显式地编写旧实体的查询，例如使用库（例如）来编写转换代码，可能是有益的