Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrazione 12 -> 14: Le migrazioni account.invoice -> account.move avvengono nella sequenza sbagliata, creando errori #3102

Open
aleuffre opened this issue Dec 23, 2022 · 22 comments

Comments

@aleuffre
Copy link
Contributor

aleuffre commented Dec 23, 2022

EDIT:

Riporto qui il problema reale riscontrato, sperando di dare più visibilità alla cosa. #3102 (comment)

Le migrazioni 12 -> 14 della maggior parte dei moduli l10n-italy (ad esempio: l10n_it_fatturapa, l10n_it_withholding_tax, l10n_it_ricevute_bancarie) per me falliscono a causa di questi problemi; alcune non falliscono solo per il caso fortunato di cui sopra (esistono le account.move e le account.move.line con gli ID corretti in modo che i constraint di foreign key vengano soddisfatti temporaneamente prima che vengano effettivamente aggiornati gli ID con quelli corretti in post-migration).

ORIGINAL:
Ciao a tutti,

sto cercando di migrare varie installazioni di Odoo CE dalla versione 12 alla 14 utilizzando Openupgrade, e sto avendo vari errori sui moduli l10n-italy legati direttamente o indirettamente alle migrazioni marcate con la versione 13.

Quando vanno eseguite esattamente le migrazioni 13.0.?
Mi sembra di aver capito, ma correggetemi se sbaglio, che le migrazioni per 13.0.
, sia pre- che post-migration, debbano essere eseguite PRIMA di ogni migrazione 14.0.* dei moduli Italiani, ma su un DB altrimenti già migrato alla 14.

Cosa ho provato:

1

  • Aggiorna moduli all'ultima versione 12
  • Aggiorna a Openupgrade 13 odoo --update all --stop-after-init rimuovendo il codice dei moduli l10n-italy (ricevo dei warning, ma il processo continua)
  • Aggiorna a Openupgrade 14 odoo --update all --stop-after-init --load=base,web,openupgrade_framework con moduli l10n-italy 14

Errore: La pre-migrate 14.0.1.0.0 di l10n_it_fatturapa https://github.com/OCA/l10n-italy/blob/14.0/l10n_it_fatturapa/migrations/14.0.1.0.0/pre-migrate.py esegue prima della post-migrate 13.0.1.0.0 https://github.com/OCA/l10n-italy/blob/14.0/l10n_it_fatturapa/migrations/13.0.1.0.0/post-migrate.py e le table non sono ancora state rinominate.

2

  • Aggiorna moduli all'ultima versione 12
  • Aggiorna a Openupgrade 13 odoo --update all --stop-after-init con moduli l10n-italy 14.0

Pro: Vengono eseguite solo le migrazioni marcate con 13.0.*, ma:

Errore: La pre-migration di l10n_it_reverse_charge 13.0 presuppone che esista la colonna move_id su account_payment, ma questa esiste solo sulla versione 14 del modulo account.

and aml.move_id not in (select move_id from account_payment);

Sto effettuando altre prove con sequenze di operazioni alternative, anche se mi sembrano improbabili, ad esempio:

  • Aggiorna moduli all'ultima versione 12
  • Aggiorna a Openupgrade 13 odoo --update all --stop-after-init rimuovendo il codice dei moduli l10n-italy (ricevo dei warning, ma il processo continua)
  • Aggiorna a Openupgrade 14 odoo --update all --stop-after-init --load=base,web,openupgrade_framework rimuovendo il codice dei moduli l10n-italy
  • Esecuzione manuale delle migrazioni 13.0.*
  • Aggiornamento dei moduli l10n-italy alla versione 14.

Vi chiedo aiuto su quale dovrebbe essere la sequenza di operazioni corretta per effettuare la migrazioni.

Grazie per il vostro tempo.

@TheMule71
Copy link
Contributor

Pingo @andreampiovesana @francescapenso @OmniaSolutions perché allo Sprint Code 2022 di Pordenone hanno fatto un tavolo sulla migrazione.

@eLBati
Copy link
Member

eLBati commented Dec 27, 2022

La procedura corretta dovrebbe essere:

@aleuffre
Copy link
Contributor Author

aleuffre commented Dec 27, 2022

Ciao,

vi ringrazio entrambi per la risposta.

Purtroppo la procedura come descritta (che era anche come avevo capito andasse fatta inizialmente, quindi almeno quello mi rincuora) non funziona.

Errore: La pre-migrate 14.0.1.0.0 di l10n_it_fatturapa https://github.com/OCA/l10n-italy/blob/14.0/l10n_it_fatturapa/migrations/14.0.1.0.0/pre-migrate.py esegue prima della post-migrate 13.0.1.0.0 https://github.com/OCA/l10n-italy/blob/14.0/l10n_it_fatturapa/migrations/13.0.1.0.0/post-migrate.py e le table non sono ancora state rinominate.

Log dell'errore
2022-12-23 17:13:08,015 1 INFO prod odoo.modules.loading: Loading module l10n_it_fatturapa (113/124) 
2022-12-23 17:13:08,119 1 INFO prod odoo.modules.migration: module l10n_it_fatturapa: Running migration [>14.0.1.0.0] pre-migrate 
2022-12-23 17:13:08,231 1 INFO prod OpenUpgrade: l10n_it_fatturapa: pre-migration script called with version 12.0.3.0.3 
2022-12-23 17:13:08,231 1 INFO prod OpenUpgrade: model faturapa.activity.progress: renaming to fatturapa.activity.progress 
2022-12-23 17:13:08,232 1 DEBUG prod OpenUpgrade: 1 rows affected after 0:00:00.000571 running UPDATE ir_model SET model = 'fatturapa.activity.progress' WHERE model = 'faturapa.activity.progress' 
2022-12-23 17:13:08,232 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000353 running UPDATE ir_model_data SET model = 'fatturapa.activity.progress' WHERE model = 'faturapa.activity.progress' 
2022-12-23 17:13:08,235 1 DEBUG prod OpenUpgrade: 1 rows affected after 0:00:00.003099 running UPDATE ir_model_data SET name='model_fatturapa_activity_progress' WHERE name='model_faturapa_activity_progress' AND model = 'ir.model' 
2022-12-23 17:13:08,256 1 DEBUG prod OpenUpgrade: 9 rows affected after 0:00:00.020000 running UPDATE ir_model_data imd
            SET name = 'field_' || 'fatturapa_activity_progress' || '__' || imf.name
            FROM ir_model_fields imf
            WHERE imd.model = 'ir.model.fields'
                AND imd.name = 'field_' || 'faturapa_activity_progress' || '__' || imf.name
                AND imf.model = 'faturapa.activity.progress' 
2022-12-23 17:13:08,256 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000474 running UPDATE ir_attachment SET res_model = 'fatturapa.activity.progress' WHERE res_model = 'faturapa.activity.progress' 
2022-12-23 17:13:08,257 1 DEBUG prod OpenUpgrade: 9 rows affected after 0:00:00.001087 running UPDATE ir_model_fields SET model = 'fatturapa.activity.progress' WHERE model = 'faturapa.activity.progress' 
2022-12-23 17:13:08,270 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.013000 running UPDATE ir_translation SET name='fatturapa.activity.progress' || substr(name, strpos(name, ',')) WHERE name LIKE 'faturapa.activity.progress,%' 
2022-12-23 17:13:08,271 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000614 running UPDATE ir_filters SET model_id = 'fatturapa.activity.progress' WHERE model_id = 'faturapa.activity.progress' 
2022-12-23 17:13:08,272 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000524 running 
            UPDATE ir_property
            SET res_id = replace(res_id, 'faturapa.activity.progress,', 'fatturapa.activity.progress,')
            WHERE res_id like 'faturapa.activity.progress,%' 
2022-12-23 17:13:08,275 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.002932 running SELECT id FROM ir_model_fields WHERE relation = 'faturapa.activity.progress' AND ttype = 'many2one' 
2022-12-23 17:13:08,278 1 DEBUG prod OpenUpgrade: 1 rows affected after 0:00:00.002730 running UPDATE ir_model_fields SET relation = 'fatturapa.activity.progress' WHERE relation = 'faturapa.activity.progress' 
2022-12-23 17:13:08,288 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000773 running UPDATE ir_exports SET resource = 'fatturapa.activity.progress' WHERE resource = 'faturapa.activity.progress' 
2022-12-23 17:13:08,289 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000518 running UPDATE ir_act_server SET model_name = 'fatturapa.activity.progress' WHERE model_name = 'faturapa.activity.progress' 
2022-12-23 17:13:08,292 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.001086 running UPDATE mail_message SET model='fatturapa.activity.progress' where model='faturapa.activity.progress' 
2022-12-23 17:13:08,293 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000549 running UPDATE mail_message_subtype SET res_model='fatturapa.activity.progress' where res_model='faturapa.activity.progress' 
2022-12-23 17:13:08,294 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000598 running UPDATE mail_template SET model='fatturapa.activity.progress' where model='faturapa.activity.progress' 
2022-12-23 17:13:08,296 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.001350 running UPDATE mail_followers SET res_model='fatturapa.activity.progress' where res_model='faturapa.activity.progress' 
2022-12-23 17:13:08,297 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000548 running UPDATE mail_activity SET res_model='fatturapa.activity.progress' where res_model='faturapa.activity.progress' 
2022-12-23 17:13:08,298 1 INFO prod OpenUpgrade: model faturapa.summary.data: renaming to fatturapa.summary.data 
2022-12-23 17:13:08,298 1 DEBUG prod OpenUpgrade: 1 rows affected after 0:00:00.000602 running UPDATE ir_model SET model = 'fatturapa.summary.data' WHERE model = 'faturapa.summary.data' 
2022-12-23 17:13:08,299 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000487 running UPDATE ir_model_data SET model = 'fatturapa.summary.data' WHERE model = 'faturapa.summary.data' 
2022-12-23 17:13:08,302 1 DEBUG prod OpenUpgrade: 1 rows affected after 0:00:00.002635 running UPDATE ir_model_data SET name='model_fatturapa_summary_data' WHERE name='model_faturapa_summary_data' AND model = 'ir.model' 
2022-12-23 17:13:08,322 1 DEBUG prod OpenUpgrade: 16 rows affected after 0:00:00.020347 running UPDATE ir_model_data imd
            SET name = 'field_' || 'fatturapa_summary_data' || '__' || imf.name
            FROM ir_model_fields imf
            WHERE imd.model = 'ir.model.fields'
                AND imd.name = 'field_' || 'faturapa_summary_data' || '__' || imf.name
                AND imf.model = 'faturapa.summary.data' 
2022-12-23 17:13:08,323 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000652 running UPDATE ir_attachment SET res_model = 'fatturapa.summary.data' WHERE res_model = 'faturapa.summary.data' 
2022-12-23 17:13:08,325 1 DEBUG prod OpenUpgrade: 16 rows affected after 0:00:00.001668 running UPDATE ir_model_fields SET model = 'fatturapa.summary.data' WHERE model = 'faturapa.summary.data' 
2022-12-23 17:13:08,337 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.011578 running UPDATE ir_translation SET name='fatturapa.summary.data' || substr(name, strpos(name, ',')) WHERE name LIKE 'faturapa.summary.data,%' 
2022-12-23 17:13:08,338 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000437 running UPDATE ir_filters SET model_id = 'fatturapa.summary.data' WHERE model_id = 'faturapa.summary.data' 
2022-12-23 17:13:08,338 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000585 running 
            UPDATE ir_property
            SET res_id = replace(res_id, 'faturapa.summary.data,', 'fatturapa.summary.data,')
            WHERE res_id like 'faturapa.summary.data,%' 
2022-12-23 17:13:08,341 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.002790 running SELECT id FROM ir_model_fields WHERE relation = 'faturapa.summary.data' AND ttype = 'many2one' 
2022-12-23 17:13:08,343 1 DEBUG prod OpenUpgrade: 1 rows affected after 0:00:00.001622 running UPDATE ir_model_fields SET relation = 'fatturapa.summary.data' WHERE relation = 'faturapa.summary.data' 
2022-12-23 17:13:08,348 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000130 running UPDATE ir_exports SET resource = 'fatturapa.summary.data' WHERE resource = 'faturapa.summary.data' 
2022-12-23 17:13:08,348 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000205 running UPDATE ir_act_server SET model_name = 'fatturapa.summary.data' WHERE model_name = 'faturapa.summary.data' 
2022-12-23 17:13:08,349 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000202 running UPDATE mail_message SET model='fatturapa.summary.data' where model='faturapa.summary.data' 
2022-12-23 17:13:08,350 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000195 running UPDATE mail_message_subtype SET res_model='fatturapa.summary.data' where res_model='faturapa.summary.data' 
2022-12-23 17:13:08,350 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000256 running UPDATE mail_template SET model='fatturapa.summary.data' where model='faturapa.summary.data' 
2022-12-23 17:13:08,351 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000173 running UPDATE mail_followers SET res_model='fatturapa.summary.data' where res_model='faturapa.summary.data' 
2022-12-23 17:13:08,351 1 DEBUG prod OpenUpgrade: 0 rows affected after 0:00:00.000191 running UPDATE mail_activity SET res_model='fatturapa.summary.data' where res_model='faturapa.summary.data' 
2022-12-23 17:13:08,352 1 INFO prod OpenUpgrade: table faturapa_activity_progress: renaming to fatturapa_activity_progress 
2022-12-23 17:13:08,357 1 INFO prod OpenUpgrade: table faturapa_summary_data: renaming to fatturapa_summary_data 
2022-12-23 17:13:08,359 1 INFO prod OpenUpgrade: table faturapa_activity_progress_id_seq: renaming to fatturapa_activity_progress_id_seq 
2022-12-23 17:13:08,361 1 INFO prod OpenUpgrade: table faturapa_summary_data_id_seq: renaming to fatturapa_summary_data_id_seq 
2022-12-23 17:13:08,539 1 INFO prod odoo.modules.registry: module l10n_it_fatturapa: creating or updating database tables 
2022-12-23 17:13:08,931 1 INFO prod odoo.schema: Keep unexpected index ir_attachment_res_model_index on table ir_attachment 
2022-12-23 17:13:08,959 1 ERROR prod odoo.sql_db: bad query: ALTER TABLE "fatturapa_related_document_type" ADD FOREIGN KEY ("invoice_id") REFERENCES "account_move"("id") ON DELETE cascade
ERROR: insert or update on table "fatturapa_related_document_type" violates foreign key constraint "fatturapa_related_document_type_invoice_id_fkey"
DETAIL:  Key (invoice_id)=(8) is not present in table "account_move".
 
2022-12-23 17:13:08,962 1 WARNING prod odoo.modules.loading: Transient module states were reset 
2022-12-23 17:13:08,964 1 ERROR prod odoo.modules.registry: Failed to load registry 
2022-12-23 17:13:08,965 1 ERROR prod click_odoo.env_options: exception 
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/click_odoo/env_options.py", line 191, in _invoke
    with self.environment_manager(
  File "/usr/local/lib/python3.8/contextlib.py", line 113, in __enter__
    return next(self.gen)
  File "/usr/local/lib/python3.8/site-packages/click_odoo_contrib/update.py", line 284, in OdooEnvironmentWithUpdate
    _update_db(
  File "/usr/local/lib/python3.8/site-packages/click_odoo_contrib/update.py", line 255, in _update_db
    _update_db_nolock(
  File "/usr/local/lib/python3.8/site-packages/click_odoo_contrib/update.py", line 233, in _update_db_nolock
    Registry.new(database, update_module=True)
  File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 455, in load_modules
    processed_modules += load_marked_modules(cr, graph,
  File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 347, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 199, in load_module_graph
    registry.init_models(cr, model_names, {'module': package.name}, new_install)
  File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 420, in init_models
    self.check_foreign_keys(cr)
  File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 504, in check_foreign_keys
    sql.add_foreign_key(cr, table1, column1, table2, column2, ondelete)
  File "/opt/odoo/custom/src/odoo/odoo/tools/sql.py", line 170, in add_foreign_key
    cr.execute(query.format(tablename1, columnname1, tablename2, columnname2, ondelete))
  File "<decorator-gen-3>", line 2, in execute
  File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 101, in check
    return f(self, *args, **kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 300, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: insert or update on table "fatturapa_related_document_type" violates foreign key constraint "fatturapa_related_document_type_invoice_id_fkey"
DETAIL:  Key (invoice_id)=(8) is not present in table "account_move".

Error: insert or update on table "fatturapa_related_document_type" violates foreign key constraint "fatturapa_related_document_type_invoice_id_fkey"
DETAIL:  Key (invoice_id)=(8) is not present in table "account_move".

Io ho un'account.invoice con ID 8, ma non un'account.move con ID 8, e la colonna a questo punto della migrazione sembra ancora contenere i vecchi valori con gli ID di account.invoice.

EDIT: Ho creato delle righe dummy di account.move giusto per fare una prova; ho lo stesso problema con l10n_it_withholding_tax. Nel momento in cui Odoo legge le tabelle e aggiorna i constraint (prima della post-migrate), ci sono ancora i dati vecchi che puntanto a account.invoice.line invece di account.move.line, e il constraint fallisce.

Log dell'errore
2022-12-27 10:23:29,756 1 INFO prod odoo.modules.loading: Loading module l10n_it_withholding_tax (121/132) 
2022-12-27 10:23:29,842 1 INFO prod odoo.modules.migration: module l10n_it_withholding_tax: Running migration [>13.0.1.0.0] pre-migration 
2022-12-27 10:23:29,843 1 DEBUG prod OpenUpgrade: -1 rows affected after 0:00:00.000326 running 
        ALTER TABLE account_invoice
            ADD COLUMN IF NOT EXISTS amount_net_pay_residual numeric
         
2022-12-27 10:23:29,962 1 INFO prod odoo.modules.registry: module l10n_it_withholding_tax: creating or updating database tables 
2022-12-27 10:23:30,181 1 INFO prod odoo.models: Storing computed values of account.move.withholding_tax_amount 
2022-12-27 10:23:30,181 1 INFO prod odoo.models: Storing computed values of account.move.amount_net_pay 
2022-12-27 10:23:30,181 1 INFO prod odoo.models: Storing computed values of account.move.amount_net_pay_residual 
2022-12-27 10:23:30,423 1 ERROR prod odoo.sql_db: bad query: ALTER TABLE "account_invoice_line_tax_wt" ADD FOREIGN KEY ("invoice_line_id") REFERENCES "account_move_line"("id") ON DELETE cascade
ERROR: insert or update on table "account_invoice_line_tax_wt" violates foreign key constraint "account_invoice_line_tax_wt_invoice_line_id_fkey"
DETAIL:  Key (invoice_line_id)=(18) is not present in table "account_move_line".
 
2022-12-27 10:23:30,427 1 WARNING prod odoo.modules.loading: Transient module states were reset 
2022-12-27 10:23:30,428 1 ERROR prod odoo.modules.registry: Failed to load registry 
2022-12-27 10:23:30,428 1 CRITICAL prod odoo.service.server: Failed to initialize database `prod`. 
Traceback (most recent call last):
  File "/opt/odoo/custom/src/odoo/odoo/service/server.py", line 1201, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 455, in load_modules
    processed_modules += load_marked_modules(cr, graph,
  File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 347, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 199, in load_module_graph
    registry.init_models(cr, model_names, {'module': package.name}, new_install)
  File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 420, in init_models
    self.check_foreign_keys(cr)
  File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 504, in check_foreign_keys
    sql.add_foreign_key(cr, table1, column1, table2, column2, ondelete)
  File "/opt/odoo/custom/src/odoo/odoo/tools/sql.py", line 170, in add_foreign_key
    cr.execute(query.format(tablename1, columnname1, tablename2, columnname2, ondelete))
  File "<decorator-gen-3>", line 2, in execute
  File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 101, in check
    return f(self, *args, **kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 300, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: insert or update on table "account_invoice_line_tax_wt" violates foreign key constraint "account_invoice_line_tax_wt_invoice_line_id_fkey"
DETAIL:  Key (invoice_line_id)=(18) is not present in table "account_move_line".

Per quello chiedevo in particolare quando dovrebbero essere eseguite le migrazioni v13, perché mi sembra che debbano essere eseguite (pre- e post-) prima di quelle v14.
EDIT: Ho trovato anche questo commento, ma non l'ho capito. #1984 (comment)

Domanda collegata: perché le "procedure manuali propedeutiche" non sono state inserite in openupgrade come hanno fatto altri moduli? https://github.com/OCA/OpenUpgrade/blob/14.0/openupgrade_scripts/apriori.py È solo questione di non aver avuto tempo (in tal caso, avrei piacere a contribuire), o ci sono motivi più profondi?

@aleuffre
Copy link
Contributor Author

aleuffre commented Dec 29, 2022

Continuando a lavorare sul problema, e studiando anche le migrazioni degli altri moduli, sono arrivato ad alcune conclusioni:

  • le migrazioni da account.invoice a account.move vanno NECESSARIAMENTE fatte in una pre-migrate. Altrimenti, nel momento in cui Odoo aggiorna la foreign key di una tabella da account.invoice a account.move, il Database diventa necessariamente inconsistente, e va in errore. A meno che non si è abbastanza fortunati che, per caso, esistono account.move con ID appropriato per ogni account.invoice. Stesso discorso per le account.invoice.line e le account.move.line

  • la strategia che sta funzionando per me, per effettuare tale migrazione, necessariamente in pre-migration, è la seguente:

    • Rimuovere il constraint di foreign key dalla tabella (ALTER TABLE xxx DROP CONSTRAINT IF EXISTS x_y_fkey) (o tramite la funzione equivalente in openupgradelib)
    • Aggiornare gli ID con gli ID di account.move/account.move.line corretti
    • Lasciare che Odoo ricrei il constraint di ForeignKey durante l'aggiornamento del modulo.

    Per rendere la strategia meno distruttiva, si possono ovviamente copiare i vecchi valori in una colonna old_invoice_id.

  • Ho compreso che il motivo per cui alcune migrazioni sono marcate con 13 è solo perché si riferiscono a cambiamenti avvenuti su Odoo 13, ma a livello funzionale non cambia nulla. Le migrazioni marcate 13 e 14 vengono eseguite insieme, prima tutte le pre-migrate, e poi tutte le post-migrate, come normale.

Le migrazioni 12 -> 14 della maggior parte dei moduli l10n-italy (ad esempio: l10n_it_fatturapa, l10n_it_withholding_tax, l10n_it_ricevute_bancarie) per me falliscono a causa di questi problemi; alcune non falliscono solo per il caso fortunato di cui sopra (esistono le account.move e le account.move.line con gli ID corretti in modo che i constraint di foreign key vengano soddisfatti temporaneamente prima che vengano effettivamente aggiornati gli ID con quelli corretti in post-migration).

@bitit-it
Copy link

La procedura corretta dovrebbe essere:

* aggiornamento v12 con update all

* con il codice di openupgrade v13 (vedi https://oca.github.io/OpenUpgrade/migration_details.html#openupgrade) + moduli OCA v13 (quindi senza moduli italiani, visto che sulla 13 non sono disponibili) aggiornare il DB con update all

* con il codice di openupgrade v14 (NB: moduli `openupgrade_framework` e `openupgrade_scripts`) + moduli OCA v14
  
  * eseguire procedure manuali propedeutiche, tipo https://github.com/OCA/l10n-italy/tree/14.0/l10n_it_payment_reason#installation
  * aggiornare il DB con update all

Buon giorno, ma prima di esportare il database della 12, devo disisntallare i moduli della fatturazione elettronica?

oppure esporto il database completo?

Enrico

@aleuffre
Copy link
Contributor Author

Buon giorno, ma prima di esportare il database della 12, devo disisntallare i moduli della fatturazione elettronica?

oppure esporto il database completo?

Enrico

Ciao, non ci dovrebbe essere bisogno di disinstallare nulla, anche perché così facendo perderesti i dati esistenti.

@bitit-it
Copy link

Ok, il processo di openupgrade sulla 13 non mi sembra abbia dato errori, però odoo13 va in errore, credo perché manchi i moduli della fatturazione elettronica.
Giusto?

@matteoopenf
Copy link
Contributor

Ok, il processo di openupgrade sulla 13 non mi sembra abbia dato errori, però odoo13 va in errore, credo perché manchi i moduli della fatturazione elettronica.

Giusto?

È giusto su 13

@bitit-it
Copy link

nell'importazione del database della 13 alla 14, prima dell'upgrade però ho questo errore:
Database restore error: ERRORE: la colonna "order" non esiste RIGA 1: SELECT "model", "name", "order", "info", "state", "transient... ^

@bitit-it
Copy link

mi correggo c'erano degli errori anche sull'importazione nella 13, ho installato sulla 12, database_cleanup, dato una ripulita , cancellato un record che andava in conflitto durante l'upgrade, adesso sulla 13 sembra di aver fatto uno step avanti, riesco ad accedere all'interfaccia di odoo, ma ovviamente con diversi errori.
durante il processo di upgrade ho degli errori che sembrano riguardino i temlpate, qui i log:
https://drive.google.com/file/d/1PxPsm2fYXWBOCWLU-w_KMuBe8HMZCQUJ/view?usp=share_link

mentre nell'importazione dalla 13 a 14 ho il seguente errore:

022-12-29 18:22:45,236 413653 ERROR odoo odoo.sql_db: bad query: ALTER TABLE "fatturapa_payment_data" ADD FOREIGN KEY ("invoice_id") REFERENCES "account_move"("id") ON DELETE cascade
ERROR: ERRORE:  la INSERT o l'UPDATE sulla tabella "fatturapa_payment_data" viola il vincolo di chiave esterna "fatturapa_payment_data_invoice_id_fkey"
DETTAGLI: La chiave (invoice_id)=(15) non è presente nella tabella "account_move".
 

2022-12-29 18:22:45,241 413653 WARNING odoo odoo.modules.loading: Transient module states were reset 
2022-12-29 18:22:45,252 413653 ERROR odoo odoo.modules.registry: Failed to load registry 
2022-12-29 18:22:45,252 413653 CRITICAL odoo odoo.service.server: Failed to initialize database `odoo`. 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/service/server.py", line 1201, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/usr/lib/python3/dist-packages/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/usr/lib/python3/dist-packages/odoo/modules/loading.py", line 455, in load_modules
    processed_modules += load_marked_modules(cr, graph,
  File "/usr/lib/python3/dist-packages/odoo/modules/loading.py", line 347, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/usr/lib/python3/dist-packages/odoo/modules/loading.py", line 199, in load_module_graph
    registry.init_models(cr, model_names, {'module': package.name}, new_install)
  File "/usr/lib/python3/dist-packages/odoo/modules/registry.py", line 420, in init_models
    self.check_foreign_keys(cr)
  File "/usr/lib/python3/dist-packages/odoo/modules/registry.py", line 504, in check_foreign_keys
    sql.add_foreign_key(cr, table1, column1, table2, column2, ondelete)
  File "/usr/lib/python3/dist-packages/odoo/tools/sql.py", line 170, in add_foreign_key
    cr.execute(query.format(tablename1, columnname1, tablename2, columnname2, ondelete))
  File "<decorator-gen-3>", line 2, in execute
  File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 101, in check
    return f(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 300, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: ERRORE:  la INSERT o l'UPDATE sulla tabella "fatturapa_payment_data" viola il vincolo di chiave esterna "fatturapa_payment_data_invoice_id_fkey"
DETTAGLI: La chiave (invoice_id)=(15) non è presente nella tabella "account_move".

@francescapenso
Copy link

Ciao, chiedo scusa se rispondo con ritardo.
Io avevo seguito di più la migrazione da 12 a 14 in enterprise, per cui grossa parte della migrazione la gestisce odoo.
Però @andreampiovesana aveva scritto un documento con i vari passaggi

@bitit-it
Copy link

bitit-it commented Dec 29, 2022

Buona sera, provero a scrivere a @andreampiovesana
anche se sembra il problema descritto da @aleuffre sopra

Grazie
Enrico

@francescapenso
Copy link

francescapenso commented Dec 29, 2022 via email

@aleuffre aleuffre changed the title [Domanda] Migrazioni 13.0.* nella migrazione 12 -> 14 Migrazione 12 -> 14: Le migrazioni account.invoice -> account.move avvengono nella sequenza sbagliata, creando errori Dec 30, 2022
@aleuffre
Copy link
Contributor Author

Cambiato il titolo dell'issue, sperando di dare più visibilità al problema. Sarei felice di contribuire alla risoluzione, se approvata (lo sto già facendo per poter migrare i miei moduli, quindi non sarebbe neanche troppo lavoro in più)

@bitit-it
Copy link

Non credo Enrico, io ho fatto un upgrade di una enterprise 10 giorni fa

si scusa ho corretto il post, quasi immediatamente .

Enrico

@francescapenso
Copy link

Buona sera, provero a scrivere a @andreampiovesana anche se sembra il problema descritto da @aleuffre sopra

Grazie Enrico

Hoparlato con Andrea, mi dice che il tema lo stanno vedendo vedendo al pnlug.it e di scrivergli una mail direttamente a andrea.m.piovesana@openindustry.it

@bitit-it
Copy link

bitit-it commented Jan 3, 2023

Hoparlato con Andrea, mi dice che il tema lo stanno vedendo vedendo al pnlug.it e di scrivergli una >mail direttamente a andrea.m.piovesana@openindustry.it

Fatto.
Grazie

@aleuffre
Copy link
Contributor Author

aleuffre commented Jan 20, 2023

Scusatemi, io ho segnalato un problema specifico con le migrazioni di quasi tutti i moduli l10n-italy, un problema che credo sia abbastanza importante, e su cui nessuno sta commentando.

Ma il mio issue è diventato un ticket di supporto per @bitit-it che, per carità, ci sta richiedere supporto, lo faccio anche io a volte, e anzi, grazie sempre a chi dedica il proprio tempo per dare supporto agli altri; ma non c'entra con la mia segnalazione e anzi sta distraendo dall'argomento.

Vi chiederei gentilmente la prossima volta di aprire un issue diverso, o in alternativa posso rinominare questo issue e aprirne un altro io sulla segnalazione originale

@bitit-it
Copy link

bitit-it commented Jan 20, 2023

Ma il mio issue è diventato un ticket di supporto per @bitit-it che, per carità, ci sta richiedere supporto, lo faccio anche io a volte, e anzi, grazie sempre a chi dedica il proprio tempo per dare supporto agli altri; ma non c'entra con la mia segnalazione e anzi sta distraendo dall'argomento.

Scusa tu, ho rimosso un poi di post per evitare di far casino.

@alessandro-fiorino
Copy link

Continuando a lavorare sul problema, e studiando anche le migrazioni degli altri moduli, sono arrivato ad alcune conclusioni:

  • le migrazioni da account.invoice a account.move vanno NECESSARIAMENTE fatte in una pre-migrate. Altrimenti, nel momento in cui Odoo aggiorna la foreign key di una tabella da account.invoice a account.move, il Database diventa necessariamente inconsistente, e va in errore. A meno che non si è abbastanza fortunati che, per caso, esistono account.move con ID appropriato per ogni account.invoice. Stesso discorso per le account.invoice.line e le account.move.line

E' capitato anche a me e concordo. La combinazione che fa scaturire il problema è che i post-migrate vengono eseguiti TUTTI al termine della migrazione, indipendentemente dalla numerazione, e non esistendo moduli italiani V13 i post-migrate che avrebbero dovuto girare al termine della migrazione V12->V13 verrebbero eseguiti invece al termine del passaggio V13->V14, troppo tardi perchè la conversione degli ID delle fatture deve essere fatta prima.
L'alternativa a convertire il post-migrate V13 in un pre-migrate V14 sarebbe fare dei moduli V13 "dummy" contenenti solo la definizione dei campi e i post-migrate V13,

@sergiocorato
Copy link
Contributor

Per risolvere le varie problematiche della migrazione sto integrando le modifiche segnalate nei vari INSTALL dei moduli, questa la prima PR: OCA/OpenUpgrade#3893

@aleuffre
Copy link
Contributor Author

aleuffre commented May 30, 2023

Io ho fatto alcune fix per far funzionare le mie migrazioni. Non sono tutte, ma sono quelle che mi sono servite per migrare 4-5 installazioni.

14.0...PyTech-SRL:l10n-italy:14.0-fix-migrations

Non ho avuto tempo di metterle a posto per bene e proporle ma hanno funzionato.

Probabilmente ce ne sono altre da fare (e alcune possono essere fatte in modo più safe, più elegante, o non prendono in considerazione alcuni casi limite che a me non sono capitati) ma intanto può essere un inizio.

Se qualcuno vuole prenderne spunto e/o pulirle e proporle come PR, anche senza attribuzione o cherry-pick, fate pure senza problemi!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants