[13.0] Add ddmrp_cron_actions_as_job#81
Conversation
|
Hi @JordiBForgeFlow, @LoisRForgeFlow, |
guewen
changed the title
guewen
changed the title
|
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
guewen
changed the title
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
jgrandguillaume
left a comment
jgrandguillaume
left a comment
There was a problem hiding this comment.
LGTM for what I can judge about.
LoisRForgeFlow
left a comment
LoisRForgeFlow
left a comment
There was a problem hiding this comment.
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. ❤️ |
8 participants
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