Skip to content

Conversation

@jbaudoux
Copy link
Contributor

@jbaudoux jbaudoux commented Jun 7, 2025

Depends on:

Tested

Improvements:

  • Improve performance on each product create/write
  • Fix changing a product category as the route is propagated to children categories
  • Allow to process lots of products linked to a product category change
  • Better manage multi-company

@jbaudoux jbaudoux force-pushed the 18-mig-stock_orderpoint_mto_as_mts branch 2 times, most recently from e2f0413 to cc5c911 Compare June 7, 2025 08:43
@jbaudoux jbaudoux marked this pull request as ready for review June 7, 2025 08:46
@jbaudoux jbaudoux force-pushed the 18-mig-stock_orderpoint_mto_as_mts branch 4 times, most recently from d65e46f to 02b58a9 Compare June 7, 2025 18:35
@jbaudoux jbaudoux changed the title [18.0][MIG] stock_orderpoint_mto_as_mts: Migration to v18.0 [18.0][MIG] stock_orderpoint_mto_as_mts: Migration to v18.0 + IMP Jun 7, 2025
# Update orderpoints for MTO / not MTO products that are linked to
# these categories. A category is not bound to a company, search
# products accross all companies.
_logger.debug("Search products already as MTO")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the deal with all these debug comments?
Left-over from debugging session? or do we really want to keep them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There can be really a lot of products under that category. Showing some progress in the debug log is convenient.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm yes, but there seems to be a lot of them. It's a bit messy, but maybe it's just me.

if warehouses:
# Find all MTO products that changed to non MTO
_logger.debug("Search products not MTO anymore")
products_not_mto = original_mto_products.filtered_domain(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as before:

  • use filtered_domain only when you truly need it, otherwise prefer filtered for perf
  • if you can avoid it, especially when dealing with a potentially large number of records, filter them with search instead

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filtered domain is making a search limited to the records subset. I have the feeling I'm doing what you suggest as second point?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filtered_domain is not doing a search, it's fetching all records data and filtering in python. Maybe that's the confusion?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh indeed, I wrongly interpreted that method. I'm replacing by a search !

_logger.debug(f"Create orderpoint for MTO - chunck {i}")
ops = op_obj.create(op_vals_list_chunk)
# free memory usage
ops.invalidate_model()

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it actually improve something?

AFAICS the only thing in the loop is op_obj.create(op_vals_list_chunk), and create is flushed immediately so there's nothing really cached.

You'd probably get better peformance not spliting at all, and letting the ORM created everything on a single query

IMO this pattern only makes sense when you're reading & writing on records:

  • Reading (specially with prefetching) can easily consume lots of RAM as you keep iterating on records
  • Writing (without flushing) can also do the same, on a much smaller scale

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I measured is that increasing the chunk size is not making it faster

Copy link

@ivantodorovich ivantodorovich Jun 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My suggestion is actually to just don't split in chunks, and my point is that splitting and processing in chunks here seems pointless

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the benefit it too see it's progressing in the logs :/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

invalidate_model may still be useful is there are computed fields that are triggered after create, isn't it?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but, I mean.. KISS
Anyway, not blocking over this

@jbaudoux
Copy link
Contributor Author

jbaudoux commented Jun 10, 2025

@ivantodorovich Thanks a lot for your review. I tried to improve the code. Can you drop another review before I squash the fixup commits ?

_logger.debug(f"Create orderpoint for MTO - chunck {i}")
ops = op_obj.create(op_vals_list_chunk)
# free memory usage
ops.invalidate_model()

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but, I mean.. KISS
Anyway, not blocking over this

if warehouses:
# Find all MTO products that changed to non MTO
_logger.debug("Search products not MTO anymore")
products_not_mto = original_mto_products.filtered_domain(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filtered_domain is not doing a search, it's fetching all records data and filtering in python. Maybe that's the confusion?

@simahawk simahawk self-requested a review June 11, 2025 08:37
tuantrantg and others added 10 commits June 11, 2025 11:23
Currently translated at 100.0% (8 of 8 strings)

Translation: stock-logistics-orderpoint-16.0/stock-logistics-orderpoint-16.0-stock_orderpoint_mto_as_mts
Translate-URL: https://translation.odoo-community.org/projects/stock-logistics-orderpoint-16-0/stock-logistics-orderpoint-16-0-stock_orderpoint_mto_as_mts/it/
Currently translated at 87.5% (7 of 8 strings)

Translation: stock-logistics-orderpoint-16.0/stock-logistics-orderpoint-16.0-stock_orderpoint_mto_as_mts
Translate-URL: https://translation.odoo-community.org/projects/stock-logistics-orderpoint-16-0/stock-logistics-orderpoint-16-0-stock_orderpoint_mto_as_mts/fr/
Currently translated at 100.0% (8 of 8 strings)

Translation: stock-logistics-orderpoint-16.0/stock-logistics-orderpoint-16.0-stock_orderpoint_mto_as_mts
Translate-URL: https://translation.odoo-community.org/projects/stock-logistics-orderpoint-16-0/stock-logistics-orderpoint-16-0-stock_orderpoint_mto_as_mts/tr/
@jbaudoux jbaudoux force-pushed the 18-mig-stock_orderpoint_mto_as_mts branch 4 times, most recently from 8f3f260 to da2b4fd Compare June 11, 2025 09:47
@sebalix
Copy link
Contributor

sebalix commented Jun 11, 2025

/ocabot migration stock_orderpoint_mto_as_mts

@OCA-git-bot OCA-git-bot added this to the 18.0 milestone Jun 11, 2025
@OCA-git-bot OCA-git-bot mentioned this pull request Jun 11, 2025
7 tasks
jbaudoux added 2 commits June 11, 2025 15:47
Improve performace on each product create/write
Fix the route on the category as it is propagated to children categories
@jbaudoux jbaudoux force-pushed the 18-mig-stock_orderpoint_mto_as_mts branch from da2b4fd to 6a98ae6 Compare June 11, 2025 13:47
@jbaudoux
Copy link
Contributor Author

I removed the wrong .pot file

@jbaudoux
Copy link
Contributor Author

/ocabot merge nobump

@OCA-git-bot
Copy link
Contributor

On my way to merge this fine PR!
Prepared branch 18.0-ocabot-merge-pr-39-by-jbaudoux-bump-nobump, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit c42f992 into OCA:18.0 Jun 11, 2025
5 of 7 checks passed
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at 2c5bbbd. Thanks a lot for contributing to OCA. ❤️

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants