[19.0][OU-FIX] account: Remove error logs - #5910
Conversation
[19.0][MIG] auth_passkey_portal: nothing to do
[19.0][MIG] project_hr_skills: nothing to do
[19.0][MIG] hr_skills_event: nothing to do
…rvey [19.0][MIG] website_slides_survey
[19.0][OU-ADD] mail_plugin: Nothing to do
[19.0][OU-ADD] crm_mail_plugin: Nothing to do
[19.0][MIG] website_livechat
[19.0][MIG] website_sale_stock: nothing to do
[19.0][MIG] website_sale_slides: nothing to do
[19.0][OU-ADD] theme_default: Nothing to do
[19.0][OU-ADD] crm_sms: Nothing to do
…lrelay [19.0][OU-ADD] delivery_mondialrelay: Nothing to do
…list [19.0][MIG] website_sale_wishlist: nothing to do
The module actually needed to pre-create the column for avoiding a possible costly computation, but also to avoid checking the constraints for each sale.order.line. TT63227
[19.0][OU-ADD] event_sale: Migration script
[19.0][OU-ADD] event_booth: Nothing to do
[19.0][OU-ADD] product_expiry: Migration scripts
[19.0][OU-ADD] event_booth_sale: Nothing to do
[19.0][OU-ADD] payment_redsys: Migration scripts
[19.0][OU-ADD] mrp_product_expiry: Nothing to do
[19.0][IMP] Update analysis files
…_forum [19.0][OU-ADD] website_slides_forum: Nothing to do
…ation on PostgreSQL 13
stock_move_value() in stock_account/19.0.1.1/post-migration.py builds an
UPDATE ... FROM (SELECT ... sum(value) value ...) aggregate subquery with
a bare-word column alias (no AS) immediately after the aggregate call.
PostgreSQL 13 rejects this as a syntax error:
ERROR: syntax error at or near "value"
LINE 5: move_id, sum(value) value
^
PostgreSQL 16 accepts the same statement, which is why this is easy to
miss when re-testing on a newer engine — it is PostgreSQL-version
dependent, not data-dependent. Any 18.0 -> 19.0 migration of a database
with stock_account installed, run against a PostgreSQL 13 backend, hits
this unconditionally partway through the post-migration step.
Fix: alias the aggregate column explicitly (agg_value) and reference the
aliased name in the outer UPDATE ... SET, instead of relying on the bare
column name colliding with the outer table's own value column.
Found and reproduced during a real 15.0 -> 19.0 OpenUpgrade migration
(PostgreSQL 13 source engine). Confirmed the exact failing statement
against a live PostgreSQL 13.23 database inside a BEGIN;...ROLLBACK; and
confirmed the patched statement runs clean against the same database.
…t-migration-value-alias [19.0][FIX] stock_account: fix syntax error in stock_move_value() post-migration on PostgreSQL 13
[19.0][OU-ADD] payment_paypal: Nothing to do
- OpenUpgrade sample DB contains companies for a lot of localization CoAs, but they may not be yet loaded because the migration scripts are not done. And anyway, that message is better passed to channel adming for being aware of the problem. - WIP: locate the origin of the "Error while loading the localization..."
OCA-git-bot
added
mod:openupgrade_scripts
|
the error message is written by the account module while constructing the data for the localization. I agree with moving this to a message in the admin channel, but suggest to log an error in case the channel doesn't exist. Sooner or later I think we should provide a function in openupgradelib that can be used for that. About the issue itself: I plan to change the way the demo db is created for v20 by caching an install of (n-1) for the modules marked as migrated in the main branch, and then installing the module(s) the PR is about on that copy. Should be comparably fast and have much less side effects, such as demo data from uninstalled modules lingering. |
|
Thanks for the insights. I dug into the same. The current situation is that I don't know which origin code raise that, as it seems not done by any migration script. Do you have any clue? |
|
I think this happens in _get_chart_template_data, where it iterates through all tagged functions to build the data dict. We could squelch those messages when calling this function because we only care about the new fields on the company record, but then I'm hesitating because this might also dump helpful error messages. Ultimately, this is only a problem for our demo db, right? All other dbs should have their COAs set up correctly and it's a good thing to warn if that's not the case (or raise as proposed in the other PR). If so, won't we be better off to disable companies with an xmlid of a localization that's not yet marked as migrated? (we mark not-yet-migrated modules as uninstalled without uninstalling them, so all their data still sits in the db). |
|
But I have commented the end-migration scripts that do the |
|
@pedrobaeza please, rebase. I made an error when force pushing to 19.0 (it's already amended) |
10 participants
@Tecnativa