NDB Google App Engine 中的继承和实体列表

Question

我正在寻找存储具有共同父级的不同种类实体列表的最佳方式。我想出了以下几点：

class Action(ndb.Model):
     date = ndb.DateTimeProperty(auto_now_add = True)

class ContentAction(Action):
     content = ndb.StringProperty()

class AuthoredAction(Action):
     author = ndb.StringProperty()

class ActionContainer(ndb.Model):
    actions = ndb.StructuredProperty(Action, repeated=True, indexed=False)

不幸的是，一旦我将 2 个不同类型的实体添加到动作列表中，就无法判断该实体是哪种类型（它们都是动作）。

此外，与作为第一个添加的实体不同的类的实体的继承属性似乎丢失了。例如，在添加 ContentAction 和 AuthoredAction 之后，后一个对象是没有“author”属性的 Action。也许 StructuredProperty 只允许存储相同类型的对象？有没有更好的结构方式？

Answer 1

来自docs：

读回这样的[结构化]实体会重构原始的联系人实体 确切地。尽管地址实例是使用相同的 对于模型类的语法，它们不是成熟的实体。他们 数据存储区中没有自己的密钥。它们无法检索 独立于他们所属的联系人实体。

因此，当您读取actions 列表中的项目时，应用引擎会根据存储在那里的数据创建Action 类型的实体。因此，为什么所有这些都显示为善意Action 是有道理的。

作为使用Polymodel（我不喜欢和避免）的替代方法是使用常规的Python 类或Python 的namedtuple 和ndb 的Pickle Property，如下所示：

ContentAction = namedtuple('ContentAction', ['date', 'content'])
AuthoredAction = namedtuple('AuthoredAction', ['date', 'author'])

class ActionContainer(ndb.Model):
    actions = ndb.PickleProperty(repeated=True)

然后您可以将任何您喜欢的命名元组放入操作列表中。

如果这对您不起作用，那么您可以使用您在对另一个答案的评论中指出的 KeyProperty。

Answer 2

我不觉得这是一个很好的存储策略。如果您正在寻找属性的继承，那么您所追求的是PolyModel。

这里有一些例子： https://cloud.google.com/appengine/articles/polymodel?hl=en