This is the the driver for DB.DATASTORE described in Database abstraction with google apps script
The library reference is MPZF_EC6nOZFAjMRqCxEaUyz3TLx7pV4j
 This tutorial references the the cDataHandler and cEzyOauth2, both of which have been superseded by cDbAbstraction and cGoa which are easier to implement. If you’d rather work with those, the slides below show an example.


Background to implementation.

This driver has been tricky to implement. The Cloud Datastore calls itself  “Google Cloud Datastore: A Fully Managed NoSQL Data Storage Service” and is normally used with Google App Engine using Python, Java, PHP or Go. There is no API for Google Apps Script, it is not normally used directly from a JavaScript client, and neither is it a database as ‘we would know it’.
There is a JSON API, and along with the new concepts of entities, paths, ancestors and tricky indexing it’s quite difficult to get started with. It does have a GQL query language which is SQL-ish, but you can only use it for querying (not updating). It is also only really able to handle objects that are flat, and complicated queries need to have indexes pre-setup – in other words you need to know what you’ll ask before you ask. 
Since this is a database abstraction driver, I don’t need the full capabilities of DataStore since I only need those that are present in other databases in the sub-universe. I also need to use  Flattening an object with dot syntax to allow for multi-level object storage and querying, and because of the limitation around pre-indexing, I need to do hybrid querying with some of it happening in datastore, and more complex constraints happening in the DataHandler. 

Here is a quick primer:



Before you choose to use DataStore, you’ll need to think about quotas. It’s very easy to blow the free daily allowance – for any meaningful application you’ll probably end up paying something. There is a quota dashboard on the Google Developers Cloud console.
The data abstraction library has caching enabled from the start, so any data taken from cache doesn’t eat into your quota.


If you’ve been avoiding oAuth2, you can’t. DataStore demands authentication. The DataHandler can accept and access token, and you can easily use EzyOauth2 – taking some pain out of Apps Script API authentication to get one for both web app and regular applications. More about that later.


Although Datastore has the concept of ‘Transactions’, you can’t protect sections of code like you can when you use it with App Engine. I’m Using named locks with Google Apps Scripts to protect sensitive transactions.


There’s a little bit of setting up to do

  • Create an application in the Google Cloud Console
  • Enable datastore
  • Get some oAuth2 credentials
  • Create your app from EzyOauth2 patterns
  • Run a web app to allow access and store your access/refresh token environment.

Here’s some libraries you’ll need or are used internally


library key comments
cDataHandler Mj61W-201_t_zC9fJg1IzYiz3TLx7pV4j Abstracted interface to back end databases, and all known drivers
cCacheHandler M3reA5eBxtwxSqCEgPywb9ai_d-phDA33 Manages caching of query results
cNamedLock Mpv7vUR0126U53sfSMXsAPai_d-phDA33 Cross script locking of abstract resources
cEzyOauth2 MSaYlTXSVk7FAqpHNCcqBv6i_d-phDA33 Manages oAuth2 credentials and offline refreshing of access tokens
cFlatten MqxKdBrlw18FDd-X5zQLd7yz3TLx7pV4j Flattens complex objects to 1 level dot syntax objects  so they can be stored/queries in a 2 dimensional space
ezyOauth2  templates Patterns for web and nonweb apps for easy oath2 authentication. Take a copy of this

How it all fits together


Oauth2 pattern

As described in EzyOauth2 patterns, apps that require oAuth2 can be complicated. However, once you’ve copied the template, the pattern is simple and repeatable. Here are the steps

  • First time in – store your credentials and scope. You do this only once. You can delete this after running it once, so you don’t have to carry credentials in your code.
  • First time in, provoke a doGet() dialog by publishing as a web app to create an access and refresh token. This will grab an offline authorization which will refresh automatically when needed. These will be used for both web apps and non-webapps. However you do need to publish and run once to create the dialog. If this is a non-web app, then unpublish it again when done. Your doGet() function looks like this. If this is a web actually a webapp, then the doSomething() function is where you create your app.

If this is not a webapp, then you need something that looks like this too, where dataStoreTest is your application that is going to d the work.

More info

The datastore code

If you are interested in the implementation, you’ll find the code here

The datastore test.

If you’ve already used Database abstraction with google apps script then this will be familiar. The database access is the same for datastore as it is for any other backend. The only specific coding is setting up the handler. Here are 3 different setups for 3  different backends – datastore, and Drive. You’ll notice they are very similar. In this i’ve opted out of analytics tracking, and turned off caching- since I’m going to run the same tests on each platform to make sure I get the same result. You’ll find these tests in the Patterns template and you may find them useful to check out your set up.

Here’s a set of tests – it doesn’t matter which back end you are using. The code is the same.

See more like this in Database abstraction with google apps script