Skip to content

Multi fk fixes and better batch inserts - #55

Merged
marcelofern merged 2 commits into
mainfrom
multi-fk-fixes-and-better-batch-inserts
Mar 5, 2026
Merged

Multi fk fixes and better batch inserts#55
marcelofern merged 2 commits into
mainfrom
multi-fk-fixes-and-better-batch-inserts

Conversation

@marcelofern

Copy link
Copy Markdown
Collaborator

Summary:

Change strategy for change log copy function

Prior to this change, the change log copy function would take a list of
integers (pks) to process.

However, Postgres has a limitation that a function may only be called
with up to 100 arguments. That means that only 100 pks could be batch
processed at a time, which isn't a large sum.

This approach changes this by allowing the function itself to query a
batch of any arbitrary length (defined at the beginning of the process),
and use that batch for processing.

This allows us to batch process large quantities and thus finish the
process much faster.

Fix when referring table has multiple FKs

Prior to this change, a part of the clean_up function that changes the
name of foreign keys back to their original wasn't handling referring
tables that had more than one FK to the original table.

This commit changes that, so that no matter how many FKs a referring
table has to the original table there won't be any problems.

Prior to this change, the change log copy function would take a list of
integers (pks) to process.

However, Postgres has a limitation that a function may only be called
with up to 100 arguments. That means that only 100 pks could be batch
processed at a time, which isn't a large sum.

This approach changes this by allowing the function itself to query a
batch of any arbitrary length (defined at the beginning of the process),
and use that batch for processing.

This allows us to batch process large quantities and thus finish the
process much faster.
Prior to this change, a part of the clean_up function that changes the
name of foreign keys back to their original wasn't handling referring
tables that had more than one FK to the original table.

This commit changes that, so that no matter how many FKs a referring
table has to the original table there won't be any problems.
@marcelofern
marcelofern requested a review from a team as a code owner March 5, 2026 05:56
@github-actions

github-actions Bot commented Mar 5, 2026

Copy link
Copy Markdown

Coverage Report Results

Name Stmts Miss Branch BrPart Cover
src/psycopack/__init__.py 8 0 0 0 100%
src/psycopack/_commands.py 130 0 6 0 100%
src/psycopack/_conn.py 5 0 0 0 100%
src/psycopack/_const.py 3 0 0 0 100%
src/psycopack/_cur.py 24 0 2 0 100%
src/psycopack/_identifiers.py 12 0 2 0 100%
src/psycopack/_introspect.py 183 0 18 0 100%
src/psycopack/_logging.py 2 0 0 0 100%
src/psycopack/_psycopg.py 5 0 0 0 100%
src/psycopack/_registry.py 88 0 12 0 100%
src/psycopack/_repack.py 450 3 154 5 99%
src/psycopack/_sync_strategy.py 4 0 0 0 100%
src/psycopack/_tracker.py 182 2 46 2 98%
tests/conftest.py 19 0 0 0 100%
tests/factories.py 41 0 10 0 100%
tests/test_cur.py 20 0 2 0 100%
tests/test_fixtures.py 5 0 0 0 100%
tests/test_package.py 3 0 0 0 100%
tests/test_repack.py 941 0 18 0 100%
TOTAL 2125 5 270 7 99%

1 empty file skipped.

@marcelofern
marcelofern merged commit 3dd13bc into main Mar 5, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant