Its a foreign key violation in Table \d "product_category_account".
The migration tries to insert an account_category with id 1but there is no entry in table product_category, IIRC.
So previously the account_category in poduct_template was a boolean and I changed them to integer type. But this is not correct as now the account_category needs to be an integer pointing to an id in the product_category? I am just guessingâŠ
in the table product_category are id values from 20 - 30.
For me it is related to Migration â Tryton Documentation
it was never detected that account_category existed before it was reintroduced as a Many2One.
So I guess the simplest is to drop the boolean column and set as the migration suggest an account category after the migration.
thanks, I deleted the column account_categoryof table product_template.
I switched to the official stock module of tryton (trytond-stock==5.0.*):
https://pypi.org/project/trytond-stock/
but also with this module I run into some issues:
Traceback (most recent call last):
File "/usr/local/bin/trytond-admin", line 21, in <module>
admin.run(options)
File "/usr/local/lib/python3.7/dist-packages/trytond/admin.py", line 54, in run
activatedeps=options.activatedeps)
File "/usr/local/lib/python3.7/dist-packages/trytond/pool.py", line 160, in init
lang=lang, activatedeps=activatedeps)
File "/usr/local/lib/python3.7/dist-packages/trytond/modules/__init__.py", line 418, in load_modules
_load_modules(update)
File "/usr/local/lib/python3.7/dist-packages/trytond/modules/__init__.py", line 388, in _load_modules
load_module_graph(graph, pool, update, lang)
File "/usr/local/lib/python3.7/dist-packages/trytond/modules/__init__.py", line 216, in load_module_graph
cls.__register__(module)
File "/usr/local/lib/python3.7/dist-packages/trytond/modules/stock/configuration.py", line 168, in __register__
cls._migrate_property([], [], [])
File "/usr/local/lib/python3.7/dist-packages/trytond/modules/stock/configuration.py", line 177, in _migrate_property
fields=fields)
File "/usr/local/lib/python3.7/dist-packages/trytond/tools/multivalue.py", line 111, in migrate_property
columns + pcolumns + vcolumns, values=values))
File "/usr/local/lib/python3.7/dist-packages/trytond/backend/postgresql/database.py", line 67, in execute
cursor.execute(self, sql, args)
psycopg2.IntegrityError: null value in column "inventory_sequence" of relation "stock_configuration_sequence" violates not-null constraint
DETAIL: Failing row contains (1, null, null, null, null, 6, 3, 4, 5, 2, null, null).
You seem to have a null value in the ir_property table for the inventory sequence.
You should probably delete the row.
I tried to look for anything related to âconfigurationâ in column res in table ir_propertybut I do not see anything related to stock:
select * from ir_property where res like '%configuration%';
id | create_uid | create_date | res | value | write_uid | field | write_date | company
-------+------------+----------------------------+-----------------------+---------------+-----------+-------+------------+---------
57772 | 1 | 2015-03-05 12:50:54.873388 | party.configuration,1 | ir.lang,5 | | 908 | | 1
57773 | 1 | 2015-03-05 12:50:54.873388 | party.configuration,1 | ir.sequence,1 | | 909 | | 1
72607 | 1 | 2021-02-10 09:29:23.162843 | sale.configuration,1 | ,order | | 2050 | | 1
72608 | 1 | 2021-02-10 09:29:23.162843 | sale.configuration,1 | ,order | | 2052 | | 1
72609 | 1 | 2021-02-10 09:29:23.162843 | sale.configuration,1 | ir.sequence,9 | | 2051 | | 1
Indeed it is more because you do not have a property set for inventory sequence but you have for the shipments.
Those properties are not link via the res column but the field column.
You can either create an entry to set a property for the inventory sequence.
Or delete the other shipment sequence properties such that the migration does not try to create them but you will have to set them back once migrated.
thanks for the clarification. Is it possible to get some more information on this? How does this property set have to look like?
In addition I did not find any entities shipment in field or res.
The field is a foreign key to ir_model_field table.
There should be field named shipment_in_sequence, shipment_in_return_sequence, shipment_out_sequence, shipment_out_return_sequence and shipment_internal_sequence.
thanks again. I made a backup table of it_model_field and deleted the shipment%sequence rows:
CREATE TABLE backup_ir_model_field AS SELECT * FROM ir_model_field;
DELETE FROM ir_model_field WHERE name LIKE 'shipment%sequence';
now the migration process stops at another point:
In tag record model ir.action.report with id reports.sale.report_sale.
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 451, in parse_xmlstream
self.sax_parser.parse(source)
File "/usr/lib/python3.7/xml/sax/expatreader.py", line 111, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/lib/python3.7/xml/sax/xmlreader.py", line 125, in parse
self.feed(buffer)
File "/usr/lib/python3.7/xml/sax/expatreader.py", line 217, in feed
self._parser.Parse(data, isFinal)
File "../Modules/pyexpat.c", line 471, in EndElement
File "/usr/lib/python3.7/xml/sax/expatreader.py", line 336, in end_element
self._cont_handler.endElement(name)
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 510, in endElement
self.taghandler = self.taghandler.endElement(name)
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 295, in endElement
self.model.__name__, self.values, self.xml_id)
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 644, in import_record
db_field = self._clean_value(key, record)
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 541, in _clean_value
field_type = Model._fields[key]._type
KeyError: 'style'
Traceback (most recent call last):
File "/usr/local/bin/trytond-admin", line 21, in <module>
admin.run(options)
File "/usr/local/lib/python3.7/dist-packages/trytond/admin.py", line 54, in run
activatedeps=options.activatedeps)
File "/usr/local/lib/python3.7/dist-packages/trytond/pool.py", line 160, in init
lang=lang, activatedeps=activatedeps)
File "/usr/local/lib/python3.7/dist-packages/trytond/modules/__init__.py", line 418, in load_modules
_load_modules(update)
File "/usr/local/lib/python3.7/dist-packages/trytond/modules/__init__.py", line 388, in _load_modules
load_module_graph(graph, pool, update, lang)
File "/usr/local/lib/python3.7/dist-packages/trytond/modules/__init__.py", line 230, in load_module_graph
tryton_parser.parse_xmlstream(fp)
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 451, in parse_xmlstream
self.sax_parser.parse(source)
File "/usr/lib/python3.7/xml/sax/expatreader.py", line 111, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/lib/python3.7/xml/sax/xmlreader.py", line 125, in parse
self.feed(buffer)
File "/usr/lib/python3.7/xml/sax/expatreader.py", line 217, in feed
self._parser.Parse(data, isFinal)
File "../Modules/pyexpat.c", line 471, in EndElement
File "/usr/lib/python3.7/xml/sax/expatreader.py", line 336, in end_element
self._cont_handler.endElement(name)
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 510, in endElement
self.taghandler = self.taghandler.endElement(name)
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 295, in endElement
self.model.__name__, self.values, self.xml_id)
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 644, in import_record
db_field = self._clean_value(key, record)
File "/usr/local/lib/python3.7/dist-packages/trytond/convert.py", line 541, in _clean_value
field_type = Model._fields[key]._type
KeyError: 'style'
Your custom module reports must be updated to no more use style field.
When migrating database with custom module, the first point is to make a version of those custom modules that work on the new target. This is prior to any consideration of update the existing database.
thanks, yes this resolved this issue.
Currently I do not see any other option than going from error to error. Or is there any documentation on how custom modules need to be updated?
anyways the migration process for the modules seems to be finished: INFO trytond.modules all modules loaded.
Now I am running into this:
psycopg2.IntegrityError: duplicate key value violates unique constraint "ir_module_module_pkey"
DETAIL: Key (id)=(1) already exists.
The ir_module table looks like this:
id | create_uid | create_date | write_date | write_uid | name | state
----+------------+----------------------------+----------------------------+-----------+-----------------------+---------------
15 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:07:02.160506 | 1 | sale | activated
16 | 0 | 2015-01-20 13:18:47.669289 | 2018-07-18 23:58:35.190587 | 1 | reports | activated
17 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:07:03.946914 | 1 | template | activated
10 | 0 | 2015-01-20 13:18:47.669289 | 2018-11-20 13:20:47.705016 | 1 | <company> | activated
4 | 0 | 2015-01-20 13:18:47.669289 | | | tests | not activated
21 | 0 | 2016-03-14 00:57:50.807198 | | | report_webkit | not activated
1 | 0 | 2015-01-20 13:18:27.336357 | 2015-02-23 11:06:44.18708 | 1 | ir | activated
2 | 0 | 2015-01-20 13:18:27.336357 | 2015-02-23 11:07:01.167182 | 1 | res | activated
18 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:48.495459 | 1 | country | activated
14 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:47.518258 | 1 | currency | activated
9 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:56.752468 | 1 | ldap_authentication | activated
19 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:55.917961 | 1 | party | activated
5 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:49.433807 | 1 | company | activated
13 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:52.553243 | 1 | account | activated
7 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:55.026812 | 1 | product | activated
12 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:50.299677 | 1 | account_product | activated
20 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:07:03.023444 | 1 | stock | activated
8 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:51.829095 | 1 | account_invoice | activated
6 | 0 | 2015-01-20 13:18:47.669289 | 2015-02-23 11:06:51.061427 | 1 | account_invoice_stock | activated
Custom modules are your responsibility but you do not need a production database to upgrade to a new series. You just need to have it properly install and have tests passing.
You need to provide more information. When is it happening? Because you just said that the migration process succeeded!!!
This happened directly after the info:
INFO trytond.modules all modules loaded
When I run the migration process again this error disapeared and another custom module specific error appeared.
The sequence of the primary key seems to start from 1, but should have a next number of 22 (last value should be 21 from report_webkit):
select * from ir_module_id_seq ;
select * from ir_module_dependency_id_seq ;
this issue didnât come up again. It was resolved by running the migration (trytond-admin âŠ) again.
But now I am struggeling with another issue. Is it correct that the account_invoice module was merged into account for 5.0?
I see this error:
Exception: Reference to account_invoice.act_invoice_out_credit_note_form not found
No, both are separate. But credit note and invoice are merged nowadays.
Exception: Reference to account_invoice.act_invoice_out_credit_note_form not found
There seem to be a module which tries to inherit act_invoice_out_credit_note_form in account_invoice module. But this view doesnât exist any longer. HIH
yes thanks, this helped. I added the missing functionality to a custom module.
I still get these errors:
psycopg2.IntegrityError: duplicate key value violates unique constraint "ir_module_module_dependency_pkey"
DETAIL: Key (id)=(77) already exists.
The id changes when I run the migration process again. When I run it often enough the id increases to a value not stored in the table. But doing this for several dependencies (always running the migration approximatly 80 times) is a little bit too much. Maybe you have an idea where this issue is coming from.
The max value of the primary key of table ir_module_dependency:
SELECT MAX(id) FROM "ir_module_dependency";
is no longer in sync with the next value of the sequence generator:
SELECT nextval(pg_get_serial_sequence('ir_module_dependency', 'id'));
As the primary key has a unique constraint, the error raises.
The solution is to bring both in sync with something like this:
SELECT setval(
pg_get_serial_sequence('ir_module_dependency', 'id'),
(SELECT MAX(id) FROM ir_module_dependency) + 1);