Dogger demo mode

In Multi user apps script logger I introduced how you could integrate logging from apps script with another technology. In this case a Polymer app. Further down the page, a live demo will have been kicked off as you are reading this..

The inspector has a demo mode, where it remotely sets off a demo apps script app, which logs some imaginary data. See Dogger settings for how to control its behavior.
You can  see the results arriving in real(ish) time via the inspector. The demo app is shown below, and references my version of a library called yourDoggerServer where I have set up my preferred connection parameters.
In this example I’m creating multiple threads of logging – I can use that to filter later on.
// the Dogger defaults you like to use are already set up in your library
var Dogger = yourDoggerServer.getDogger(false);
  

// we'll use this additional thread for verbose reporting
var Verbose = yourDoggerServer.getDogger(false, 'verbose');

function doSomeStuff(e) {

  // clear the log before starting (there's no thread so it will clear the whole thing
  Dogger.clear();
  
  // try various logging
  Dogger.log('Im starting');
  
  for (var i = 0 ; i < 4 ; i++) {
    Verbose.log(Math.random());
  }
  
  Dogger.log ('heres an object');
  Dogger.log ({str:'im an object', num:20, bool: true});
  
  // what happens if we try to report a library object
  Dogger.log ('handler object up next');
  Dogger.log(Dogger);
  
  // an array
  Verbose.log([1,2,3,4,5]);
  
  // simulate some time passing and things happening
  for (var i = 0 ; i < 10 ; i++) {
    Verbose.log('Im doing something very busy ' + i);
    Utilities.sleep (2000);
  }
  
  // im done
  Dogger.log('Im done');
  
}

Starting up

This sets up my logger handle. . The actual database it will use is irrelevant to the Logging operation. It’s centrally controlled in your version of yourDoggerServer – we’ll deal with that later. I always use DriverScratch for this, since the log files will fade away by themselves if not accessed, and I don’t have to bother maintaining them.
// the Dogger defaults you like to use are already set up in your library
var Dogger = yourDoggerServer.getDogger(false);

Now everywhere I would use Logger.log()  , I can use Dogger.log(). You could even assign this to replace the Logger if you want (Logger = Dogger) and continue using Logger.log().

What does it log

You get a bit more information than you do with the normal Logger.
Most of it is obvious, but here’s a quick summary
  • seq – the row number
  • time – the time it was logged at
  • fromstart – how many seconds from the first log entry
  • fromprevious – how many seconds since the previous log entry
  • type – the data type of the message (Dogger.log(message))
  • value – the value of the message. If message was an object you’ll get a stringified version
  • length – the length of the message if relevant
  • caller – the name of the function that called the .log()
  • line – the line number where the call happened
  • file – the script file name containing the call
  • _timeStamp – the time it as logged as a timestamp
  • _thread – where given, the logging thread this message belongs to – more about threads shortly
  • name – the name of the object type of the message (if identifiable)
  • nargs – the number of arguments the constructor of an object like this is built to expect where known
For more about identifying where things are called from and what they are see How to determine what kind of object something is in Apps Script and Reporting file, function and line number in Apps Script

Threads

Sometimes its useful to categorize messages into groups. This is especially true if more than one process is contributing to the same log file. A thread is some text value you choose to assign to a message. The inspector provides a way to filter on specific threads, and you could do the same with other database or spreadsheet tools if you choose to use them.
In the example, you can see that I opened two Logger threads, one with no thread, and another where the second argument was the thread to use.
// we'll use this additional thread for verbose reporting
var Verbose = yourDoggerServer.getDogger(false, 'verbose');

From then on I can use Dogger.log(message) to create a message with no thread, and Verbose.log(message) to assign a thread name to the message.  You can see in the image below that the messages that have a thread value were written with Verbose.log() in the example given earlier.

A note on performance

This kind of logging is going to introduce overhead, since it now has to go and write things to a database. In addition, since it is multiuser by design, there is a lot of complication around locking (see Using named locks with Google Apps Scripts) to ensure that the integrity of the log is maintained when there are multiple simultaneous contributions. You can turn off locking if you are sure it’s sole use when you open the database (see Working with transactions) but in the end, this is a tradeoff between visibility with Dogger and efficiency with Logger.

Getting started

Let’s dive a little deeper into how to set this up. I recommend that you take a look at Database abstraction with google apps script if you are not already familiar with how this works.

Try the demo [Deprecated]

Note that in this demo, the  database may be used simultaneously by others trying the demo, so you may get mixed results.
What is happening is …
  • the inspector by default will be in demo mode
  • it will clear the log file and kick off the Apps Script example above
  • The Apps script example will Log stuff to a database
  • The inspector will show the log as entries arrive.

For help and more information join our community, follow the blog or follow me on Twitter . For more on this topic see Multi user apps script logger