0.19.0 - The one with (a preview of) --transform-mode

[justinvdm]

snaplet snapshot capture --transform-mode={strict,auto,unsafe}

In this release, we’re introducing a preview of a new feature we’re building: “Transform modes”:

At the moment, snaplet allows you to override your production data with replacement data using transform.ts. However, up until now we did not give any control over what happens if no override has been given. In these cases, we simply keep the production data as is.

Transform modes will give you more control over what to do when there are fields present in your data with no corresponding override in transform.ts:

• --transform-mode=strict: snaplet will fail creation of the snapshot and tell you which fields are missing from transform.ts
• --transform-mode=auto: snapshot tries to automatically transform the data for these fields, currently via copycat.scramble()
• --transform-mode=unsafe: snaplet will simply use the production data as is for these fields (the current default behaviour of snaplet)

If you are using Snaplet Cloud (app.snaplet.dev), you can specify the transform mode using a new $options.fallback key in your transform.ts:

// The transform.ts file shown in the UI at app.snaplet.dev

export const config = {
  $options: {
    fallback: 'auto'
  },
  
  SchemaFoo: {
    TableBar() {
      ...
    }
  }

  ...
}

This is an early preview of the feature though - there’s still a few rough edges, including:

• In auto mode, we are not transforming date column types correctly - the results are not dates
• For strict and auto mode, if any errors occur for a particular column, we fail straight away, rather than collecting all errors for all columns (so that you have a complete picture of what needs to be changed)

We’re working on getting this feature stable and ready for you to use, watch this space :)

Bugfixes

• Before this release, when creating a preview database, we’d give you back a URL to use to connect to your database. The problem with this URL, is that we have to wait for DNS records to update in order for it to point to a newly created or changed database instance. To solve this, we now directly use the database server IP address instead of the domain.
• A small change was made to subsetting. The secondary targets in the initial_targets setting in subsetting.json config did not always populate new entries. In this release we first iterate over all of the initial_targets and add them to the subset before we start subsetting the rest of the database.