Support real-world quirky schemas#136
Support real-world quirky schemas#136blast-hardcheese wants to merge 5 commits intopavlospt:mainfrom
Conversation
blast-hardcheese
force-pushed
the
dstewart/bug/support-quirky-schemas
branch
from
277c41d to
9bd99d1
Compare
|
Thank you very much for your PR! |
| /// Accept invalid TLS certificates for the second database | ||
| #[arg(long, default_value_t = false, required = false)] | ||
| accept_invalid_certs_second_db: bool, | ||
| /// Accept invalid TLS certificates for the second database |
|
@blast-hardcheese also please check formatting and tests |
I have to admit, it's been a few years since I did Rust, I just spun up a small dev environment with nix and found If you've got a one-liner to get a tight dev loop, that would be amazing. |
I don't have a one-liner or something to setup a dev env |
2 participants
Hello, thank you for the tool! I offer this PR after running into some issues using your tool against our schema; it was fairly easy to modify, even without knowing about the organization of the codebase, what I initially lamented as boilerplate was actually helping guide me exactly to the implementation I wanted -- really, really good work.
Features added:
Missing quotes strips load-bearing case sensitivity
Prisma, when left to its own devices, will name tables and columns without any consideration to ergonomics.
eg:
Userhas a columnenrichmentProfileExecutedAt......which when unquoted get normalized into
user.enrichmentprofileexecutedat...which are not found.
"Squashed" schema migrations are susceptible to columns being out of order.
Due to some infrastructure challenges trying to bridge the gap between CNPG and RDS, I was unable to use DDL replication, and had to resort to applying prisma migrations to bootstrap prior to starting replication.
Unfortunately, this meant that my db1 and db2 had columns that were out of order, leading to
t.*being different and the resultant hashes being incorrect.After adding a new query to select columns and order them explicitly, now validation checks pass with no problems.
Finally, we have a few tables without primary keys. This is regrettable, and I would totally understand if this is a bridge too far, but in order to get logical replication set up I had to
ALTER TABLE public."..." REPLICA IDENTITY FULL.In the same vein, I added
--replica-identity fullas a fallback strategy to work aroundNo primary key foundIn a perfect world we wouldn't need tools like pgdatadiff, but today I was tremendously grateful for it being available. Thank you!