Fix category_id import by properly handling many2many relationships a…

[bosd]

…nd field name resolution

[gemini-code-assist]

Summary of Changes

Hello @bosd, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refines the Odoo data import process, specifically addressing how many-to-many relationships are managed. It introduces a more robust mechanism to determine relational table and field names by first querying Odoo's internal metadata, then falling back to conventional derivation. Crucially, it updates the import logic to correctly use Odoo's ORM write command with the (6, 0, [IDs]) tuple for many-to-many fields, ensuring that related records are properly associated with their owning models, rather than attempting direct creation in an intermediate relational table. This change resolves potential issues with category_id imports and similar many-to-many field types.

Highlights

• Improved Many-to-Many Relationship Handling: The import logic for many-to-many fields in Odoo has been updated to correctly use the Odoo ORM's write command with the (6, 0, [IDs]) tuple, ensuring proper association of related records instead of attempting direct creation in relational tables.
• Enhanced Relation Information Derivation: The system now first queries Odoo's ir.model.relation table to accurately determine relational table and field names. If Odoo metadata is unavailable, it falls back to convention-based derivation, making the process more robust.
• Dynamic Field Name Resolution: The import functions now dynamically resolve the actual column name in DataFrames for many-to-many fields, accommodating common patterns like /id suffixes (e.g., category_id/id).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request significantly improves the import logic for many-to-many relationships by using Odoo's standard ORM write method, which is a great enhancement. The changes also add robustness by querying Odoo for relation metadata and handling field/id column name conventions. My review identified a few issues with the new implementation: a bug in determining the owning model's foreign key, a regression in the fallback logic for deriving relation table names, and a logical error in DataFrame processing within the _create_relational_records function. I have provided specific code suggestions to address these points.

[gemini-code-assist]

The link_df DataFrame passed into this function has already been processed by _prepare_link_dataframe, which includes splitting and exploding the comma-separated IDs from the source file. Therefore, the actual_field_name column in link_df already contains single, individual external IDs, not comma-separated strings.

The code here incorrectly attempts to split and explode this column again. While this might not crash, it is redundant and logically incorrect, as it's based on a wrong assumption about the DataFrame's schema at this point. This should be simplified to just rename the columns.

    original_links_df = link_df.select(["external_id", actual_field_name]).rename(
        {"external_id": "parent_external_id", actual_field_name: "related_external_id"}
    )

[bosd]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces significant improvements for handling many-to-many relationships, particularly by querying Odoo for relation metadata before falling back to name derivation, and by correctly using Odoo's write command for m2m updates. The changes are robust and well-implemented. My review focuses on opportunities to reduce code duplication, enhance performance with more idiomatic Polars usage, and refine the test suite for better clarity and precision.