-
-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[13.0] Add ddmrp_cron_actions_as_job #81
Conversation
Hi @JordiBForgeFlow, @LoisRForgeFlow, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG
OCA/queue#270 has a bug, so I'll propose a temporary alternative solution until I can fix this one |
24919eb
to
50239d7
Compare
changed implementation, and need some work from me on the queue_job PRs to be ready
I pushed a new implementation that works by patching the method instead of relying on a decorator (see OCA/queue#270 (comment)). I still need to work on OCA/queue#274 for this to be ready. |
83f87dc
to
5515cf3
Compare
5515cf3
to
b95bb31
Compare
b95bb31
to
1c31e05
Compare
Could you add the module to oca_requirements.txt? |
1c31e05
to
5c81d21
Compare
done |
5c81d21
to
a49002f
Compare
@JordiBForgeFlow @LoisRForgeFlow I included the commits of #66 with a new commit fixing issues of #66:
The duration of cron_ddmrp() (when generating jobs with ddmrp_cron_actions_as_job) goes from 8 minutes to 35 seconds. Pay attention to the usage of |
As some tests failed, I looked again at this and found some fields to invalidate: ce5d553, these are the non-stored computed fields used by |
It makes calls to "cron_actions" run in queue jobs. The jobs have an identity key with "identity_exact", meaning that only one occurence of a job for the same buffer with the same arguments (only_nfp) will be created at a time (e.g. when the state of a stock.move is changed several times in the same transaction or in a different transaction in a short timeframe). It needs OCA/queue#274 and OCA/queue#275
commits and locking the buffers for too long.
* Call commit once per chunk instead of once per record: commit flushes and clears the env, forcing a fetch of all the records of the chunk after each line. * Remove `buffer.refresh()` in cron_ddmrp(): this deprecated method calls `invalidate_cache()` without ids and field names, which forces a fetch of all the records of the chunk at each line. If it is required to invalidate something (but I could not find any explanation), we should invalidate only the ids and fields that needs invalidation (hopefully only non-stored computed fields). Or at the very least, do not fetch the 50 records of the browse at once but one by one (but that'd be a pity). The duration of cron_ddmrp() (when generating jobs with ddmrp_cron_actions_as_job) goes from 8 minutes to 35 seconds.
Fix tests: * test_22_procure_recommended * test_23_buffer_zones_all It is possible that the invalidation is only required because of the tests and would not be required at runtime. But this has been proposed in the past: OCA#59 However, this commit tries to invalidate the less possible fields to limit the computations and data to fetch again.
ce5d553
to
92ae390
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for what I can judge about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Thanks for the detailed commit messages, it eases following the rational behind the changes.
This PR has the |
/ocabot merge minor |
Hey, thanks for contributing! Proceeding to merge this for you. |
Congratulations, your PR was merged at dd449e7. Thanks a lot for contributing to OCA. ❤️ |
It makes every calls to "cron_actions" run in queue jobs.
The jobs have an identity key with "identity_exact", meaning that only
one occurence of a job for the same buffer with the same arguments
(only_nfp) will be created at a time (e.g. when the state of a
stock.move is changed several times in the same transaction or in
a different transaction in a short timeframe).
It needs OCA/queue#274 and OCA/queue#275