[13.0] Deprecate job decorators #274

guewen · 2020-10-30T17:10:45Z

@job and @related_action are still supported but emit warnings and
will be removed at some point (code to remove has a TODO with:job-no-decorator:)

The initial reasons for this change are in #273, but it also brings nice side effects:

the options previously set by the decorators are now stored on
"queue.job.function" records, which can be explicitly created
as XML records, which mean they can now be edited by users
any method can be used with "with_delay()", if no "queue.job.function"
exists, default values are used (root channel, default related
action, ...)

This one will require a major bump.

My wish is:

12.0: deprecate decorators but show no warning when they are used
13.0: deprecate decorators and show warnings when they are used
14.0: entirely remove them, as we are starting migrations, it will be easy to tackle in the modules

Remaining tasks:

Adapt tests
Document the configuration (a lot of documentation is in the decorators, move it elsewhere + in readme)
Figure out how to handle duplicates queue.job.function (not big issue though)
update other modules of the repository
As any method can be delayed, maybe we should guard create/write (on a subset of fields) on queue.job from RPC (OTOH only queue job managers can do it, but at the very least they should not be able to create a raw queue.job record for a method starting with _
More checks/constraints on config, improve views, ...
Add model / method fields on queue.job.function and compute the name from there

Fixes #273

This patch method has to be called in ``_register_hook``. When a method is patched, any call to the method will not directly execute the method's body, but will instead enqueue a job. A typical use case is when a method in a module we don't control is called synchronously in the middle of another method, and we'd like all the calls to this method become asynchronous. It relies on OCA#274 that deprecates the `@job` decorator.

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

This patch method has to be called in ``_register_hook``. When a method is patched, any call to the method will not directly execute the method's body, but will instead enqueue a job. When a ``context_key`` is set when calling ``_patch_job_auto_delay``, the patched method is automatically delayed only when this key is ``True`` in the caller's context. It is advised to patch the method with a ``context_key``, because making the automatic delay *in any case* can produce nasty and unexpected side effects (e.g. another module calls the method and expects it to be computed before doing something else, expecting a result, ...). A typical use case is when a method in a module we don't control is called synchronously in the middle of another method, and we'd like all the calls to this method become asynchronous. It relies on OCA#274 that deprecates the `@job` decorator.

@job

* @job and @related_action are still supported but emit warnings and will be removed at some point (code to remove has a TODO with :job-no-decorator:) * the options previously set by the decorators are now stored on "queue.job.function" records, which can be explicitly created as XML records (and then editable!) * any method can be used with "with_delay()", if no "queue.job.function" exists, default values are used (root channel, default related action, ...)

As previously, the job functions and channels were created automatically by "_register_job" on methods decorated by `@job`, databases have records without xmlids. To prevent duplicates (or unique constraint error) in case of channels, the create method automatically merges the new record with the existing record. This behavior happens only when installing/upgrading a module, records created manually behave normally. If 2 modules adds the same channel or job function, they'll be merged together with 2 xmlids, on uninstallation of one of the module, the record will be kept thanks to the second xmlid.

This patch method has to be called in ``_register_hook``. When a method is patched, any call to the method will not directly execute the method's body, but will instead enqueue a job. When a ``context_key`` is set when calling ``_patch_job_auto_delay``, the patched method is automatically delayed only when this key is ``True`` in the caller's context. It is advised to patch the method with a ``context_key``, because making the automatic delay *in any case* can produce nasty and unexpected side effects (e.g. another module calls the method and expects it to be computed before doing something else, expecting a result, ...). A typical use case is when a method in a module we don't control is called synchronously in the middle of another method, and we'd like all the calls to this method become asynchronous. It relies on OCA#274 that deprecates the `@job` decorator.

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

This patch method has to be called in ``_register_hook``. When a method is patched, any call to the method will not directly execute the method's body, but will instead enqueue a job. When a ``context_key`` is set when calling ``_patch_job_auto_delay``, the patched method is automatically delayed only when this key is ``True`` in the caller's context. It is advised to patch the method with a ``context_key``, because making the automatic delay *in any case* can produce nasty and unexpected side effects (e.g. another module calls the method and expects it to be computed before doing something else, expecting a result, ...). A typical use case is when a method in a module we don't control is called synchronously in the middle of another method, and we'd like all the calls to this method become asynchronous. It relies on OCA#274 that deprecates the `@job` decorator.

base_import_async/data/queue_job_function_data.xml

As we can delay a job on any method, and the queue.job model is accessible from RPC (as any model), prevent to: * create a queue.job using RPC * write on protected fields (e.g. method name) using RPC Admittedly, the risk is low since users need have Queue Job Manager access to create/write on jobs, but it would allow these users to call internal methods. The check is done using a context key that must be equal to a sentinel object, which is impossible to pass through RPC.

A many2one to select the model + a char for the method name is more convenient and error-proof than having to type the expected format correctly.

Following changes in OCA/queue#274

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

Following changes in OCA/queue#274

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

Following changes in OCA/queue#274

This patch method has to be called in ``_register_hook``. When a method is patched, any call to the method will not directly execute the method's body, but will instead enqueue a job. When a ``context_key`` is set when calling ``_patch_job_auto_delay``, the patched method is automatically delayed only when this key is ``True`` in the caller's context. It is advised to patch the method with a ``context_key``, because making the automatic delay *in any case* can produce nasty and unexpected side effects (e.g. another module calls the method and expects it to be computed before doing something else, expecting a result, ...). A typical use case is when a method in a module we don't control is called synchronously in the middle of another method, and we'd like all the calls to this method become asynchronous. It relies on OCA#274 that deprecates the `@job` decorator.

Following changes in OCA/queue#274

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

This patch method has to be called in ``_register_hook``. When a method is patched, any call to the method will not directly execute the method's body, but will instead enqueue a job. When a ``context_key`` is set when calling ``_patch_job_auto_delay``, the patched method is automatically delayed only when this key is ``True`` in the caller's context. It is advised to patch the method with a ``context_key``, because making the automatic delay *in any case* can produce nasty and unexpected side effects (e.g. another module calls the method and expects it to be computed before doing something else, expecting a result, ...). A typical use case is when a method in a module we don't control is called synchronously in the middle of another method, and we'd like all the calls to this method become asynchronous. It relies on OCA#274 that deprecates the `@job` decorator.

guewen mentioned this pull request Nov 2, 2020

[13.0] Add method to patch a method to be automatically delayed #275

Merged

This was referenced Nov 2, 2020

[13.0] Add ddmrp_cron_actions_as_job OCA/ddmrp#81

Merged

[ON HOLD][13.0] Add job_auto_delay decorator #270

Closed

[14.0][MIG] queue job: Migration to 14.0 #263

Closed

guewen force-pushed the 13.0-deprecate-decorators branch from ee2527c to 098acd2 Compare November 2, 2020 09:46

guewen force-pushed the 13.0-deprecate-decorators branch 5 times, most recently from 762e2b4 to 6fe6bf8 Compare November 2, 2020 13:58

guewen changed the title ~~[13.0][WIP] Deprecate job decorators~~ [13.0] Deprecate job decorators Nov 2, 2020

guewen force-pushed the 13.0-deprecate-decorators branch from c38e2e0 to 14712ca Compare November 2, 2020 14:33

guewen added 3 commits November 2, 2020 16:30

Update documentation for deprecation of decorators

59e3eaf

guewen force-pushed the 13.0-deprecate-decorators branch from 14712ca to 013b7a6 Compare November 2, 2020 15:30

guewen marked this pull request as ready for review November 2, 2020 15:47

guewen force-pushed the 13.0-deprecate-decorators branch from 013b7a6 to f2036ef Compare November 2, 2020 15:47

This comment has been minimized.

Sign in to view

lmignon reviewed Nov 2, 2020

View reviewed changes

base_import_async/data/queue_job_function_data.xml Show resolved Hide resolved

guewen added 2 commits November 2, 2020 21:19

Replace job function name by model + method fields

27687b2

A many2one to select the model + a char for the method name is more convenient and error-proof than having to type the expected format correctly.

hailangvn pushed a commit to phuctranfxvn/stock-logistics-warehouse that referenced this pull request Sep 16, 2021

Remove @job decorator

f3d5029

Following changes in OCA/queue#274

hailangvn pushed a commit to phuctranfxvn/stock-logistics-warehouse that referenced this pull request Oct 7, 2021

Remove @job decorator

3dcf2c5

Following changes in OCA/queue#274

hailangvn pushed a commit to phuctranfxvn/stock-logistics-warehouse that referenced this pull request Oct 8, 2021

Remove @job decorator

aec61b5

Following changes in OCA/queue#274

lmignon pushed a commit to acsone/stock-logistics-warehouse that referenced this pull request Nov 3, 2022

Remove @job decorator

9dea80c

Following changes in OCA/queue#274

kaynnan pushed a commit to Escodoo/stock-logistics-warehouse that referenced this pull request Jul 18, 2023

Remove @job decorator

42a12cf

Following changes in OCA/queue#274

TOP-10-DEV added a commit to TOP-10-DEV/stock-logistics-warehouse that referenced this pull request Dec 8, 2023

Remove @job decorator

c1828e5

Following changes in OCA/queue#274

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[13.0] Deprecate job decorators #274

[13.0] Deprecate job decorators #274

guewen commented Oct 30, 2020 •

edited

Loading

This comment has been minimized.

[13.0] Deprecate job decorators #274

[13.0] Deprecate job decorators #274

Conversation

guewen commented Oct 30, 2020 • edited Loading

This comment has been minimized.

guewen commented Oct 30, 2020 •

edited

Loading