Keys and EntityGroups
每个entity 都有一个key,是entity 提供唯一的标识给应用程序。一个key 有几个组成部分:一个路径描述它和其它entity 之间的父子关系;Entity 的表类;程序给entity 的一个名字或者datastore给entity 的一个数字ID。
· Kinds, Names and IDs
· Entity Groups, Ancestors and Paths
· Paths and Key Uniqueness
Kinds, Names and IDs
每个entity 属于一个特定表类。查询可以返回一组entity。不象table 中的行,尽管应用程序能够在数据模型中建立约束,2个同表类的entity不一定具有完全一样的属性。datastore API 用 Model或者 Expando 的子类的名字作为表类的名字。
例如,这个类定义了一个模型给一个”Story”种类
class Story(db.Model):
title = db.StringProperty()
author = db.StringProperty()
每个 entity 有一个标识。一个应用程序可以赋值这个标识,在建立实例的时候用key_name参数就可以了
s = Story(key_name="xzy123")
如果没有指定 key_name ,datastore 缺省会给它一个数字id
s2 = Story() # s2 does not have a name or an ID.
s2.put() # s2 is given an ID by the datastore.
一旦建立,entity 的ID 或者名字不能改变
提示:在查询语句中key值不能象属性一样使用。但是你可以用一个命名了的key,并把名称作为属性存储。如果是数字ID 的话,可以通过 obj.key().id() 获取ID 的值,然后赋给一个属性,然后对这个属性来排序就等于对id 排序了
Entity Groups, Ancestors and Paths
每个entity 属于一个entity组。单个事务可以操作一组entity。Entity组的关系告诉appengine 在分布式网络同一部分储存几个entity。一个事务为一个entity组建立起datastore的操作,要么全部成功要么全部失败。
当应用程序创建一个entity,它能够把另外一个entity赋值为它的父亲。这个操作把新的entity并到父亲的同一组。
没有父亲的entity 是根entity。父子关系可以多级。从根节点开始的链称为entity的路径。这个路径上的entity都是它的祖先。Entity创建的时候,父亲就指定了并且不能被改变。
每个entity 和它的父亲entity都属于同一组。所有同组的entity 都储存于datastore 的同一个节点。同一个事务可以修改同组的多个entity,或者为新增的entity 指定现存的entity作为父亲。
如果一个entity 是一个已经删除的entity 的祖先,它的后代将不会被删除,后代仍然保留这继承路径。
通过指定继承路径,你可以先于创建父亲来创建一个 entdity 。为了实现,你使用 keyname 创建一个 key 给祖先,然后用它作为新 entity 的父亲。所有具备相同的根祖先的 entity 都属于同一组。无论这个 root 祖先是否一个真正的 entity 。提示
· 只有需要事务的时候才使用entity组。其它的一些数据关系请使用ReferenceProperty和key值,他们可以在query 里面使用。
· 你的程序用entity组用的越多,就是说,越多的根entity,datastore就能够越有效率的使用节点存储这些entity。更好的分布可以提高创建和更新的性能。并且多用户在试图同时更新同组的entity的时候会导致一些事务的重新执行,可能导致失败。不要把所有的entity 放在同一个root.
· A goodrule of thumb for entity groups is that they should be about the size of asingle user's worth of data or smaller.
· Entity 分组不会对查询有明显的影响。
Paths and KeyUniqueness
一个entity完整的key,包括路径,类型和名字或者数字ID,是唯一标识entity 的。Entity创建的时候完整的key就已经被创建了。上述的任何一部分都不能改变。
2个不同的enttiy的key既有相同的部分也有不同的部分。例如,如果他们的父亲一样那么类型和名字就一样。类似地,2个不同类型的entity 可以有相同的父亲。
应用程序不应依赖数字ID的创建顺序来判断entity 的创建顺序。通常这样,但不保证。