You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[12.0 -> 13.0] [product] Error while updating product module #2983
migration v12 to v13
experiencing same issue as this one : #2268
Excpet that the message is indicating that comibination_indices are not computed :
File "/home/florent.thomas/DEV/Odoo_Server_And_Libs/Servers_13/OpenUpgrade/odoo/sql_db.py", line 250, in execute
res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « product_product_combination_unique »
DÉTAIL : La clé « (product_tmpl_id, combination_indices)=(13, ) » existe déjà.
Excpet that the message is indicating that comibination_indices are not computed :
No, the message is saying that the are two products which have the same combination_indices, and that a constrain forbids it. Then this error can only happen if the query in calculate_product_product_combination_indices of pre-migration doesn't assure the uniqueness. I hope that with #2987 the problem is solved.
@flotho after doing a deeper analysis of the issue, let me ask you a question. In your v12 db, do you have two variant products of the same template and both without attributes?
I mean, could you do in your DB in v12 the following query and see if it shows any record?
SELECTpp1.id, pp2.idFROM product_product pp1
JOIN product_template pt ONpp1.product_tmpl_id=pt.idJOIN product_product pp2 ON (pp2.product_tmpl_id=pt.idANDpp1.id!=pp2.id)
WHEREpp1.id NOT IN (SELECT product_product_id FROM product_attribute_value_product_product_rel)
ANDpp2.id NOT IN (SELECT product_product_id FROM product_attribute_value_product_product_rel);
Here is the state of the product.template(2) and variants :
As you can see, there is NO duplicate values and none of the variants is archived.
Then I ran the upgrade and as you can see below, the upgrade process is not retrieving attribute value ids bound to the product product (causing an empty computation of the combination_indices )
Yet I still have the issue :
As you can see there is an empty combination_indices (causing duplicate issue of #2268 ) instead of having an indice correctly computed with the attribute value existing in v12.
So what we first cans say it's that the #2987 is not solving this issue.
The second one confirms that the upgrade process is not finding any values for product_template_attribute_value_ids so that combination_indices is not well computed.
My thought is that the issue is really coming from #2983 (comment) the field has changed its definition and the table combination_indices is not filled by its relations coming from the v12.
I think that all this example seems to confirm my PR proposal to create the table in the pre migration process #2984
I hope that i gave enough information to you @MiquelRForgeFlow for comparing our analysis.
@flotho finally I understood your problem. But i don't understand why you have this problem but I still don't have this problem in any other dbs I have migrated. As you explained, in the update of the module, the new table product_variant_combination is created empty and also the new constraint product_product_combination_unique is checked, so in theory everybody should have this error, right?
@flotho finally I understood your problem. But i don't understand why you have this problem but I still don't have this problem in any other dbs I have migrated. As you explained, in the update of the module, the new table product_variant_combination is created empty and also the new constraint product_product_combination_unique is checked, so in theory everybody should have this error, right?
well you know, theory is like wonderland and it looks like unicorn ;-)
but you're totally right I don't know why other people don't have this.
Maybe we could keep the post install script and add the pre install as it's executed only if the table is empty.
do you observe at the same place in the code the same results ?
Regards
Activity
flotho commentedon Nov 28, 2021
even worse, it is computed in the v12 : https://github.com/OCA/OpenUpgrade/blob/12.0/addons/product/models/product.py#L121
MiquelRForgeFlow commentedon Nov 29, 2021
No, the message is saying that the are two products which have the same combination_indices, and that a constrain forbids it. Then this error can only happen if the query in calculate_product_product_combination_indices of pre-migration doesn't assure the uniqueness. I hope that with #2987 the problem is solved.
MiquelRForgeFlow commentedon Nov 29, 2021
@flotho after doing a deeper analysis of the issue, let me ask you a question. In your v12 db, do you have two variant products of the same template and both without attributes?
I mean, could you do in your DB in v12 the following query and see if it shows any record?
flotho commentedon Nov 29, 2021
Hi @MiquelRForgeFlow
thanks for digging so far. Here is the result of your query :

no duplicate values
MiquelRForgeFlow commentedon Nov 30, 2021
thanks @flotho . Could you give more info about your error? a longer log? and please use last update of the v13, as we did a change.
flotho commentedon Dec 11, 2021
So here is some additional information regarding the state of the migration.

First, I've pulled your latests v13.0 updates :
the result of your query still the same #2983 (comment)
Here is the state of the product.template(2) and variants :

As you can see, there is NO duplicate values and none of the variants is archived.
Then I ran the upgrade and as you can see below, the upgrade process is not retrieving attribute value ids bound to the product product (causing an empty computation of the combination_indices )

Yet I still have the issue :

As you can see there is an empty combination_indices (causing duplicate issue of #2268 ) instead of having an indice correctly computed with the attribute value existing in v12.
So what we first cans say it's that the #2987 is not solving this issue.
The second one confirms that the upgrade process is not finding any values for product_template_attribute_value_ids so that combination_indices is not well computed.
My thought is that the issue is really coming from #2983 (comment) the field has changed its definition and the table combination_indices is not filled by its relations coming from the v12.
I think that all this example seems to confirm my PR proposal to create the table in the pre migration process #2984
I hope that i gave enough information to you @MiquelRForgeFlow for comparing our analysis.
Thanks for reading
flotho commentedon Dec 11, 2021
and more logs for the error :

flotho commentedon Dec 11, 2021
ping @MiquelRForgeFlow , more info in this thread
MiquelRForgeFlow commentedon Dec 13, 2021
@flotho finally I understood your problem. But i don't understand why you have this problem but I still don't have this problem in any other dbs I have migrated. As you explained, in the update of the module, the new table product_variant_combination is created empty and also the new constraint product_product_combination_unique is checked, so in theory everybody should have this error, right?
[OU-FIX] product: move logic from post to pre-migration
flotho commentedon Dec 14, 2021
well you know, theory is like wonderland and it looks like unicorn ;-)
but you're totally right I don't know why other people don't have this.
Maybe we could keep the post install script and add the pre install as it's executed only if the table is empty.
do you observe at the same place in the code the same results ?
Regards
MiquelRForgeFlow commentedon Dec 14, 2021
Of course. Thus we will apply your fix and that's all. This way we can't forget about this. I have tuned your fix here #3011.