0.26.0 - The one where we gather capture errors

[justinvdm]

Before this release, if you created a new snapshot for your db at app.snaplet.dev or ran snaplet snapshot capture, we’d stop on the very first error that happened, and let you know about this error.

After solving that error and creating a new snapshot again, you might run into a new error, at which point snaplet would stop there and tell you about that error. After solving that error, you would create yet another snapshot, and so on.

In this release, we’ve improved this workflow: when capturing snapshots, snaplet now finds out about all the errors it can up front - so that you have the information you need to fix all of them before trying to creating a snapshot again.

The way snaplet does this is as follow: for each row, in each table, in each schema, we try to transform that row according to the contents of transform.ts. If there were any errors when transforming that row (there could be several if multiple column transformations threw errors), we collect the errors that happened, stop processing that table and move onto the next table. Right at the end, we let you know about all the errors we’ve collected if there were any.

snaplet ss capture —-transform-mode=strict

In 0.19.0, we released a preview of a new feature: transform modes - where you can now tell snaplet what to do about data that you haven’t told it explicitly how to transform:

• --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)

In this release, we’ve made --transform-mode=strict more helpful: we’re now able to tell you about all fields that need to be added to your transform.ts at once, rather than only tell you about the next one snaplet finds (only for you to need to re-run snaplet again to find out about the next, next field after accounting for that field).

Bug fixes and improvements

• When Snaplet logs unhandled errors to the console, there would be some unnecessary noise added to the logs: "this error originated either by throwing inside of an async function…”. This noise made it more difficult for anyone to see what the actual issue was, so we’ve now made sure we’re only logging about the actual issue (without this noise).
• In order to create a snapshot for your database, Snaplet first collects information about your database to help it know how to capture the snapshot. Part of the information we collect is relation information for subsetting your database. We’re now showing more detailed error messages for the errors we show during this stage so that you (and we) have a better idea of what the underlying issue is.