Multi user apps script logger introduced the concept of an apps script Logger that could write to an abstracted database. In order to set up your own Logging environment (the demos you may have looked at so far are using a public version of mine), there are a few one off tasks you need to take care of.
In order to keep the access and caches private to you, you need to clone, customize or create the items in pink below. For those in blue, you can use the libraries I provide (or fork if you prefer)


This is a shared library in which you centralize the setting up your logging databases and credentials. if you want to use the Inspector client (or write your own), you’ll also need this to be published as a webapp to serve up JSON/JSONP of your log database contents.

Setting up the database handler

In this example I’m using DriverScratch as the DB, since I want the data to be self cleaning. You could choose another if you prefer. See Database abstraction with google apps script for examples.


Create a script called yourDoggerServer, and add this to it – adapting the credentials as you wish.
This profile will now become your default logging place and credentials. The credentials (siloid, cachecommunity and dbid) are all needed to be able to access this log database, and will match those you set up in Dogger settings if you are using the inspector

A note on caching

Every database backend can use caching for query results. By default it will. Query caching is at its most effective when you have multiple requests for the same data with no writes in between. However it does use up some resource so you should decide whether this is worthwhile for your case and set disablecache accordingly.
In the case of DriverScratch – which I’ve chosen to use in this example, cache is actually used for the database itself (as well as for caching query results). You’ll notice that I’ve asked it to use a specific cache here. By default it will use the cache associated with the cDogger library but you will probably want to use your own cache for this instead.


I recommend centralizing your cache allocation through a specific library. This way you can share its contents across multiple apps. It’s an optional to do this (you could use the cDogger cache, or the cache of yourDoggerServer), but you’ll see the benefits for this approach later if you become a regular Database abstraction with google apps script user.
Create a script called yourCacheBucket, and add this code to it

Adding libraries

Now go back to yourDoggerServer, and add the libraries you’ll need (adapting the driver to the specific database you’ll need, and applying the key for yourCacheBucket (instead of mine).
The button below will get you info on where to get the library code, source code and other info on all these libraries and their dependencies.

Creating a webapp

If you are planning to use the Multi user apps script logger inspector (or some other app that needs JSON/JSONP API access), regardless of the backend you’ve chosen to use, you’ll need to add this to yourDoggerServer script and publish as a webapp. It is the key of this published webapp (along with the credentials you set up earlier), that you’ll need to provide in Dogger settings if you are using the Polymer Inspector app.

Adding dependency information.

When I create libraries, I like to add dependency info (as described in Get GAS library info) to them. If you want to you can add these to each of your libraries, substituting the detail for the information for your libraries.

A note on libraries

It is possible to use the cDogger library directly from each script that you want to log in this way (avoiding creating these 2 libraries), but the minimal effort in doing this will save you a lot of time later on.
For help and more information join our community,  follow the blog or  follow me on Twitter