Question

在升级采用GAE时,更新数据模型的最佳方式是什么?

申请的版本允许分多个版本,但这些版本使用同样的数据储存(见)。如何在部署到谷歌应用引擎后改变应用?。因此,当我用不同的数据模型上载一份应用软件时,会发生什么情况(这里的我想是什么时候,但问题也应该对 Java有效)? 我认为,如果这些变化增加了一个无法否认的领域和一些新类别,那么它就是一个问题,这样,现有的模式就可以在没有损害的情况下加以推广。但是,如果数据模型的变化更为深远? 如果现有数据与新的数据模型不一致,我是否实际上丧失了数据?

我目前看到的唯一选择是将数据储存置于只读的方式中,使数据脱节并再次部署。

Answer 1

There are few ways of dealing with that and they are not mutually exclusive:

Make a non-breaking changes to your datastore and work around the issues it creates. Inserting new fields into existing model classes, switching fields from required to optional, adding new models, etc. - these won t break compatibility with any existing entities. But since those entities do not magically change to conform to new model (remember, datastore is a schema-less DB), you might need a legacy code that will partially support the old model. For example, if you have added a new field, you will want to access it via getattr(entity, "field_name", default_value) rather than entity.field_name so that it doesn t result in AttributeError for old entities.
逐步将这些实体转化为新的形式。这非常简单:如果你发现一个仍然使用旧模式的实体,会作出适当改动。在上述例子中,你希望使实体重新加入新的领域:
```
if not hasattr(entity, "field_name"):
    entity.field_name = default_value
    entity.put()
val = entity.field_name # no getattr ing needed now
```
理想的情况是,所有贵实体都将最终以这种方式处理,你将能够在某个时候取消转换法。实际上,总是有一些遗留问题,应当手工转换——这使我们可以选择第3号。
Batch-convert your entities to new format. The complexity of logistics behind this depends greatly on the number of entities to process, your site s activity, resources you can devote to the process, etc. Just note that using straightforward MapReduce may not be the best idea - especially if you used the gradual convert technique described above. This is because MapReduce processes all entities of given kind (fetching them) while there may only be a tiny percentage needing that. Hence it could be beneficial to code the conversion code by hand, writing the query for old entities explicitly and e.g. using a library such as ndb.

友情链接