Commit Graph

13 Commits

Author SHA1 Message Date
fabianlindfors
49b01bbb28 Version 0.3.1 2022-01-16 23:00:46 +01:00
fabianlindfors
9cac25299a Refactor tests to use test framework
This has the added benefit of removing the need for builders and the
derive_builder dependency.
2022-01-15 16:15:31 +01:00
fabianlindfors
17376ce3b7 Version 0.3.0 2022-01-14 12:38:21 +01:00
fabianlindfors
24e1d4b902 Version 0.2.0 2022-01-12 13:19:27 +01:00
fabianlindfors
c76ea1fba6 Add builder for create_table migration
The builder will help simplify the tests and avoid boilerplate updates
when need fields are added to the create_table migration. We might want
to add builders all migrations later.
2022-01-10 21:59:20 +01:00
fabianlindfors
435a40695a Bump crate version to 0.1.1 2022-01-08 16:09:23 +01:00
fabianlindfors
bd50686d32 Remove unused bimap dependency 2022-01-04 15:08:12 +01:00
fabianlindfors
1ddfe95bf0 Add backtrace feature to anyhow
Improved backtrace support for errors in Rust is currently in progress:
https://github.com/rust-lang/rust/issues/53487. Adding the feature lets
anyhow add backtraces already which greatly improves readability of
errors in tests.
2022-01-03 22:03:10 +01:00
fabianlindfors
da8a5c3c77 Upgrade clap to 3.0.0 2022-01-03 00:05:54 +01:00
fabianlindfors
86254abe63 Add metadata to Cargo.toml 2022-01-01 17:35:16 +01:00
fabianlindfors
b44145b568 Update clap and add derive feature flag 2021-12-27 14:11:43 +01:00
fabianlindfors
9f23ed38c1 Remove explicit schema tracking
Before, we explicitly tracked the current schema and relied on that in
our migrations. This makes things more complicated as we need to keep
track of not just tables and columns but also primary keys, constraints
etc.

This commit remove the schema tracking and instead queries the
database for the current schema. During migrations, we temporarily store
the changes that are made, for example having temporary columns override
real ones and combine these with the current schema in the database.
This is handled in schema.rs.

These changes also broke our previously handling of triggers and
functions and how we detected if an insert/update was made against the
old or new schema during a migration. The previous method, using a
temporary __reshape_is_new column has been replaced with some helper
functions which inspect the search_path setting and uses that to
determine which schema is being used. During migrations, we can also set
the custom "reshape.is_old_schema" setting to force the old schema, for
example during batch updates.

This greatly simplifies the triggers as we can now simply call a helper
function in Postgres, `reshape.is_old_schema()`, to determine which
schema the modification was made for.
2021-12-27 12:40:57 +01:00
fabianlindfors
7d8302a0a4 Initial commit 2021-10-26 00:31:09 +02:00