Here are the Database abstraction with google apps script release notes for March 2015. Modules in scope and dependencies can be found on github.
March 3rd 2015 – v2.2
This is a medium sized update, mainly concerned with enabling RipDB – scriptDB emulator
- Version numbers. These have been harmonized. This release is v2.2. Each dbAbstraction specific driver that has been updated as part of this updated will be versioned as v2.2.x.
- RipDB – scriptDB emulator. This is a layer on top of db abstraction that emulates the now deprecated ScriptDB service. It may be of some interest if you still have small ScriptDb projects around that you haven’t converted, since the layer is a replication of the ScriptDb syntax and structure – in other words you can migrate to DbAbstraction from ScriptDB without changing your script except for adding the library and the driver of your choice.
- Keys. All underlying platforms have the concept of an immutable key that is associated with a particular data object, except for DriverSheet. Initially I had intended that I would add no data to a sheet to differentiate it from a normal sheet, but the lack of a permanent key identifying a particular object in the sheet driver is adding too much complication to the overall solution. As of this version, an extra column will be present in each sheet that is used by the DriverSheet with a unique key for each row. Older sheets will be updated automatically when accessed with DriverSheet 2.2 onwards. This key column can be hidden/unhidden with an option when you create the handler.
- DriverIds. Because of the changes in driversheet, the whole business of key handling can be much simpler. Over time I’ll be stripping out some of the now redundant key handling code starting with the driverIds array that can be returned from query() and get(). handleKeys will still be available but will now be a an array of strings rather than the previously mixed return types. This should have no user effect since handleKeys were simply passed on to get() functions anyway.
- save(). This now uses driver specific solutions to figure out the ids of the newly written objects. These will be returned in result.handleKeys() and the original data that was written will be returned in save.data. This behavior is standardized across all current drivers.
- removeByIds(array of ids). This method is now implemented for all backends. It allows you to provide the array returned in result.handleKeys to delete all matching objects.
- DriverOrchestrate. The Orchestrate infrastructure takes a while to propagate changes – if you write something, that change may not be reflected if you query immediately afterwards. This is not controllable from the script since the issue is not about committing the data – it’s about a propagation delay in the Orchestrate infrastructure itself. There is now a dbAbstraction option when you get your handler (option.waitafter) where you can specify a number of milliseconds to wait after a write operation. It can apply to all drivers, but by default is 0 for them all (and not needed) aside from Orchestrate which has a default of 1500. If you don’t care about the propagation delay, you can set this to 0 for Orchestrate too.
- DriverDataStore. I haven’t updated driver datastore in this release, since I don’t think that anyone is using it. If you are, please let me know, otherwise I may decide to deprecate it.