Java Reference
In-Depth Information
to have the same properties or types, your application must enforce adherence to
your data model, whatever that may be at the time. A property can have one or more
values, embedded classes, child objects, and even values of mixed types. Entities are
very flexible and are not defined by a database schema as in a relational database. At
any point during the application life cycle you can add or remove entity properties.
Newly created and fetched entities will utilize this new schema. Your application's
logic must be able to handle these changes.
App Engine uses the Java Persistence API (JPA)) and Java Data Objects (JDO))
interfaces for modeling and persisting entities. These APIs, rather than the low-level
API, ensure application portability. For your application, you'll use JDO since the
Eclipse plug-in generates your JDO configuration files. Of course, JPA is supported,
but it requires some additional setup and configuration steps. If you are familiar with
Hibernate or other object-relational mapping (ORM) ) solutions, JDO should be fairly
easy to grok as these solutions share many features.
App Engine's JDO implementation is provided by the DataNucleus Access
Platform, an open-source implementation of JDO 2.3. Again, the JDO specification is
database-agnostic and defines high-level interfaces for annotating simple POJOs,
persisting and querying objects, and utilizing transactions. Applications
implementing JDO can query for entities by property values or they can fetch a
specific entity from the datastore using its key. Queries can return zero or more
entities and sort them by property values, if desired.
Classes and Fields
JDO uses annotations on POJOs to describe how these objects are persisted to the
datastore and how to recreate them when they are, in turn, fetched from the datastore.
The kind of entity is defined by the simple name of the class while each class member
specified as persistent represents a property of the entity. The data class is required to
have a field dedicated to storing the primary key of its corresponding entity.
Each entity has a key that is unique to Bigtable. Keys consist of the application ID, the
entity ID, and the kind of entity. Some keys may also contain information pertaining to
the entity group. Your application can generate keys for your entities, or you can allow
Bigtable to automatically assign numeric IDs for you. In most cases it is easier to let
Bigtable assign your keys so you don't have to write code to ensure that your keys are
unique across all objects of the same kind plus entity group parent (if being used).
There are four types of primary key fields:
1.
Long
: An ID that is automatically generated by Bigtable when the
instance is saved.
2.
Uncoded String
: An ID or "key name" that your application
provides to the instance prior to being saved.
