Skip to content

[15.0][OU-ADD] ptplus_accounting + ptplus_stock: migration scripts (15.0.5.0.0)#12

Open
eantones wants to merge 7 commits into
15.0from
15.0-ou-add-ptplus
Open

[15.0][OU-ADD] ptplus_accounting + ptplus_stock: migration scripts (15.0.5.0.0)#12
eantones wants to merge 7 commits into
15.0from
15.0-ou-add-ptplus

Conversation

@eantones

Copy link
Copy Markdown
Member

Split of #3 (fork-only part). Migration scripts for the Oxigen PT Plus custom modules: pre-create + batched recompute of l10n_pt_account_expected_balance / l10n_pt_is_national, VAT-adjustment-norm dedup, no-commit fix inside the batched recomputes. Never intended for OCA — these modules are customer-specific.

Files (disjoint from the sibling split PRs): openupgrade_scripts/scripts/ptplus_accounting/15.0.5.0.0/* + openupgrade_scripts/scripts/ptplus_stock/15.0.5.0.0/*.

eantones added 7 commits July 12, 2026 19:53
The 15.0.5.0.0 vendor upgrade adds this stored computed field on
account.move.line. On a large database the ORM's column-creation mass
compute ("Storing computed values") loads millions of rows into the
cache on top of ~300 modules' worth of upgrade state and the process is
OOM-killed. Pre-creating the column in a pre-migration makes _auto_init
skip the mass init (the openupgradelib.add_fields mechanism); the field
is recomputed in controlled batches at the target version.
The 15.0.5.0.0 vendor upgrade adds this stored computed field on
stock.picking. Same mass-compute OOM as ptplus_accounting's
l10n_pt_account_expected_balance: pre-creating the column makes the ORM
skip the whole-table init; the field is recomputed in controlled batches
at the target version.
…te before rename

Databases that already carry l10n_pt_vat_adjustment_norm_id alongside the
old vat_adjustment_norm_id duplicate crash the module's own pre-migration:
its openupgrade.rename_fields() finds the target column already present.
Drop the old duplicate first, guarded to abort if it holds any data.
The pre-00- basename makes it run before the module's own pre-migration.py
(same-version stage scripts execute in basename order).
…balance

Fill the field pre-created empty by pre-migration.py, in memory-safe chunks
using the model's own compute via the ORM (add_to_compute + flush), so the
vendor's real compute logic runs without ever reading the packaged code.
Runs in post-migration at 15.0.5.0.0, so the field is created AND filled
within this same hop — no cross-version dependency, each hop self-contained.
Fill the field pre-created empty by pre-migration.py, in memory-safe chunks
using the model's own compute via the ORM (add_to_compute + flush), so the
vendor's real compute logic runs without ever reading the packaged code.
Runs in post-migration at 15.0.5.0.0, so the field is created AND filled
within this same hop — no cross-version dependency, each hop self-contained.
@openupgrade.migrate() wraps the script in a savepoint: a cr.commit() per
chunk destroys it (RELEASE SAVEPOINT crashes on script exit, aborting the
whole upgrade at the finish line) and breaks per-module transactionality.
Memory stays bounded by the per-chunk cache invalidation alone; the
recompute measured ~3 minutes for 2.28M rows.
Same savepoint/transactionality fix as ptplus_accounting: the decorator
wraps the script in a savepoint that a mid-loop commit destroys. Cache
invalidation per chunk alone keeps memory bounded.
@eantones eantones added the local-only Contains commits that stay in this repo forever (customer-private modules, local policy). label Jul 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

local-only Contains commits that stay in this repo forever (customer-private modules, local policy).

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant