Database Reference
In-Depth Information
model = ndb.StringProperty(indexed=False,
validator=_validate_str)
os = ndb.StringProperty(indexed=False,
choices=('android', 'ios'))
os_version = ndb.StringProperty(indexed=False,
validator=_validate_version)
storage_gb = ndb.IntegerProperty(indexed=False)
screen = ndb.LocalStructuredProperty(Screen)
carrier = ndb.StringProperty(indexed=False)
home_zip5 = ndb.StringProperty(indexed=False,
validator=_verify_zip5)
This snippet is from the
models.py
file in the sample application described
in Chapter 8, “Putting it Together.” Even without understanding all the
details of the client API, it should be apparent this is defining something
very much like a schema. By default, the client API uses the name of the class
as the
kind
of the records. Note that there is no explicit table creation step.
A kind exists as long as one or more entities with the appropriate key exist.
Here is a code snippet for creating a
Device
entity:
device = Device(id=base64.b64encode(os.urandom(9),
'-_'))
device.owner = user
device.type = self.request.get('type')
device.make = self.request.get('make')
…
device.put()
The sensor application supports the creation and deletion of these device
records to allow users to register and unregister their phones and tablets
with the application.
When the client component of the sensor application logs a record from a
device, it includes the ID stored in the registration record for the device.
You can easily imagine that a lot of interesting queries would be possible
if it was possible to join the log records with the device records using the
ID. Fortunately, you can get this done easily if you can accept a snapshot
of the data in Datastore. For the purpose of the sensor application, a daily
