Class DatastoreServiceConfig (2.0.0)

User-configurable properties of the datastore.

Notes on usage:
The recommended way to instantiate a DatastoreServiceConfig object is to statically import Builder.* and invoke a static creation method followed by an instance mutator (if needed):

 import static com.google.appengine.api.datastore.DatastoreServiceConfig.Builder.*;
 import com.google.appengine.api.datastore.ReadPolicy.Consistency;

 ...

 // eventually consistent reads
 DatastoreServiceConfig config = withReadPolicy(new ReadPolicy(Consistency.EVENTUAL));

 // eventually consistent reads with a 5 second deadline
 DatastoreServiceConfig config =
   withReadPolicy(new ReadPolicy(Consistency.EVENTUAL)).deadline(5.0);
 

This is the name of a system property that determines how the Java SDK writes/reads empty lists to/from Datastore.

Historically Datastore has not had the ability to represent an empty list in its persistent store. Different SDKs have made different decisions on what to write to Datastore when a client attempts to insert an empty list to the persistent store. The Java SDK has historically written both empty lists and null values as null values to the persistent store.

With the release of this flag, Datastore can now represent empty lists within its persistent store. This means that Datastore SDKs can distinguish between empty lists and null values. This property controls whether this SDK writes an empty list as empty list or null to the persistent store.

A note on queries: Null values can be indexed by Datastore which means they can interact with queries. For example queries that find all entities with null values or order by a property will include null values. Empty lists are not indexable by Datastore and so cannot appear in similar queries.

Thus, if this flag was unset (the old behavior) and an empty list was stored into the persistent store, it could appear in query results because it was really stored as a null value.

If this flag is set (the new behavior) and an empty list is stored into the persistent store, it will not appear it query results because it is stored as an empty list.

When this variable is set to anything other than "true" the system provides legacy behavior.

• Null properties are written as null to Datastore
• Empty collections are written as null to Datastore
• A null is read as null from Datastore
• An empty collection is read as null. Note that a read modify write of an entity with an empty list will cause that list to be turned into a null value.

When this variable is set to "true":

• Null properties are written as null to Datastore
• Empty collections (#Collection#isEmpty()) are written as empty list to Datastore
• A null is read as null from Datastore
• An empty collection is read as null
• When reading from Datastore an empty list is returned as an empty Collection.

It is strongly recommended that this property be set to true in order to provide compatibility with other Datastore SDK's, as well as future versions of Datastore.

To set the flag: System.setProperty(DatastoreServiceConfig.DATASTORE_EMPTY_LIST_SUPPORT, Boolean.TRUE.toString());

Returns whether or not empty list support is enabled; see #DATASTORE_EMPTY_LIST_SUPPORT.

Sets the deadline, in seconds, for all rpcs initiated by the DatastoreService with which this config is associated.

Returns the deadline, in seconds, to use. Can be null.

Returns the ImplicitTransactionManagementPolicy to use.

Returns the maximum number of entity groups per rpc.

Returns the ReadPolicy to use.

Sets the implicit transaction management policy.

Sets the maximum number of entity groups that can be represented in a single rpc.

For a non-transactional operation that involves more entity groups than the maximum, the operation will be performed by executing multiple, asynchronous rpcs to the datastore, each of which has no more entity groups represented than the maximum. So, if a put() operation has 8 entity groups and the maximum is 3, we will send 3 rpcs, 2 with 3 entity groups and 1 with 2 entity groups. This is a performance optimization - in many cases multiple, small, asynchronous rpcs will finish faster than a single large asynchronous rpc. The optimal value for this property will be application-specific, so experimentation is encouraged.

Sets the read policy.