Skip to content

[12.0 -> 13.0] [product] Error while updating product module #2983

Closed

Description

@flotho

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à.

AFAICS, the definition of the field has changed https://github.com/OCA/OpenUpgrade/blob/13.0/addons/product/models/product.py#L100 with an explicit name of a relation so that the computation here https://github.com/OCA/OpenUpgrade/blob/13.0/addons/product/models/product.py#L215 always returning an empty combination indices.

I think that the solution should be to rename the relation table in the pre script.
@pedrobaeza , do you agree with this analysis ?

Regards

Activity

  1. flotho commented on Nov 28, 2021

    @flotho
    MemberAuthor
  2. MiquelRForgeFlow commented on Nov 29, 2021

    @MiquelRForgeFlow
    Contributor

    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.

  3. MiquelRForgeFlow commented on Nov 29, 2021

    @MiquelRForgeFlow
    Contributor

    @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?

    SELECT pp1.id, pp2.id
    FROM product_product pp1
    JOIN product_template pt ON pp1.product_tmpl_id = pt.id
    JOIN product_product pp2 ON (pp2.product_tmpl_id = pt.id AND pp1.id != pp2.id)
    WHERE pp1.id NOT IN (SELECT product_product_id FROM product_attribute_value_product_product_rel)
        AND pp2.id NOT IN (SELECT product_product_id FROM product_attribute_value_product_product_rel);
  4. flotho commented on Nov 29, 2021

    @flotho
    MemberAuthor

    Hi @MiquelRForgeFlow

    thanks for digging so far. Here is the result of your query :
    image
    no duplicate values

  5. MiquelRForgeFlow commented on Nov 30, 2021

    @MiquelRForgeFlow
    Contributor

    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.

  6. flotho commented on Dec 11, 2021

    @flotho
    MemberAuthor

    So here is some additional information regarding the state of the migration.
    First, I've pulled your latests v13.0 updates :
    image

    the result of your query still the same #2983 (comment)

    Here is the state of the product.template(2) and variants :
    image

    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 )
    image

    Yet I still have the issue :
    image
    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

  7. flotho commented on Dec 11, 2021

    @flotho
    MemberAuthor

    and more logs for the error :
    image

  8. flotho commented on Dec 11, 2021

    @flotho
    MemberAuthor

    ping @MiquelRForgeFlow , more info in this thread

  9. MiquelRForgeFlow commented on Dec 13, 2021

    @MiquelRForgeFlow
    Contributor

    @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?

  10. flotho commented on Dec 14, 2021

    @flotho
    MemberAuthor

    @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

  11. MiquelRForgeFlow commented on Dec 14, 2021

    @MiquelRForgeFlow
    Contributor

    well you know, theory is like wonderland and it looks like unicorn

    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.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions