0.29.0 - The partial one

[justinvdm]

In this release, we've introduced the concept of partial captures and restores of database snapshots:

Partial captures

Before this release, when creating a snapshot of your database, if there were tables or schemas in the database that it did not have access to, Snaplet would fail to create the entire snapshot.

Snaplet will now only try create a snapshot for the schemas and tables where we have enough privileges to read data. More specifically, tables where the user has SELECT permissions, within schemas where the user has USAGE permissions.

note: Snaplet now also needs BYPASSRLS permissions in order to capture data for databases with row-level security policies. Check out our docs for our guide on creating a ready-only user with the minimum permissions necessary for it to create snapshots.

Partial restores

In this release, when doing a snaplet snapshot restore, Snaplet will try to restore all the database structure and data that is in the snapshot. If any part of the structure or data restoring failed, Snaplet would log the failure as a warning, but continue to restore the database.

This was already the case before, with one exception - the reset step: Before Snaplet restores the database from a snapshot, it first drops the current schemas, along with their tables and other related objects so that we have a clean slate before restoring. However, if we failed to drop any of these schemas, the entire restore would fail. In this release, if Snaplet cannot drop a schema, it will instead fall back to truncating all tables within that schema. If it fails to truncate any tables, Snaplet will still continue with truncating any remaining tables in that schema, then continue with dropping any other remaining schemas, then continue on with the rest of the restore. All the way through, Snaplet will log any failures that happen.

⚠️ To note for Supabase users

Before this release, Snaplet had some special-case logic for capturing and restoring databases hosted on Supabase. For example, we'd avoid trying to drop specific schemas that we know the user does not own (e.g. auth). We found this approach to be quite fragile: it made Supabase a moving target (e.g. if any new schemas were added to new Supabase projects), and also did not work in cases where we could not infer that the project was hosted on Supabase (e.g. a local Supabase docker instance). With these new partial capture and restore concepts, we no longer need this logic, and so we've done away with it. However, this does mean that you can now expect to see some warnings when restoring snapshots - these warnings are Snaplet showing what it was not able to do, but does not mean the restore failed:

• Snaplet will log warnings about schemas it was not able to drop since the user is not the owner (e.g. auth). It will still truncate all tables in these schemas before restoring the snapshot
• Snaplet will log warnings about not being able to create schemas or objects inside of these schemas as a result of these schemas already existing. The restore will still continue, and any data we have captured for objects inside of these schemas will still be restored.