Implement abstract base models to make the base models more extendable #305
Comments
|
I'm working on that and I'll send the pull request with the needed changes soon. |
|
cool |
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 10, 2022
Added a `helpers` module into `models` containing the functions
`taskresult_model()` and `groupresult_model()`.
* `taskresult_model()`: will try to find the custom model using a
dotted path defined under the constant
`CELERY_RESULTS_TASKRESULT_MODEL` in the settings of the user's project
* `groupresult_model()` will try to do the same using under the
constant `CELERY_RESULTS_GROUPRESULT_MODEL`.
By default if these attributes are not found `django-celery-results`
will use the default models (`models.TaskResult` and
`models.GroupResult`).
Updated database backend in order to use custom models for `TaskResult
and `GroupResult` it they're present.
Instead to import explicitely the `TaskResult` and the `GroupResult`
(default models from `django-celery-results`) we make use of the model
helpers to load the right classes, the custom ones if they're present
otherwise we use the default ones.
Getting data from `task_kwargs` to extend the `task_properties` and be
able to store them into the database (using the custom models).
First of all we need a way to get data from `task_kwargs` (or somewhere
else) just before a `task_result` record is created, evaluate that data
and find the right values that will be used to fill the new fields
defined in the custom model.
So for this purpose we added a settings module to
`django-celery-results` which will hold default settings, the first
setting that will contain is a function in charge to get a callback from
the settings of the user project. This callback will be feeded by the
task `task_kwargs`, which will be intercepted in
`DatabaseBackend._get_extended_properties` just before the `task_kwargs`
are encoded by `encode_content()` method and send it to the
`store_result` method from the object manager of `TaskModel`
(Custom/Default one).
To end, we must to extend the arguments of the `store_result` method
from the `TaskResult` Manager adding `**extra_fields` that will make us
able to send extra data to the custom model, when it's defined.
---
Resolves celery#305
Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 10, 2022
`extend_task_props_callback` moved from `_get_extended_properties` to `_store_result`. Suggested by @AllesVeldman. `extend_task_props_callback` will get the `request` object as first parameter and a copy of `task_props` (avoiding potential manipulation of the original `task_props`) as second paramenter. --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 15, 2022
`get_callback_function()` gets a default callback as an arg returning explicitely an empty dict. `get_callback_function()` raises an `ImproperlyConfigured` exception when the callback is not callable. --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 17, 2022
Added `get_task_props_extension` to `settings` module which will raise an `ImproperlyConfigured` when the task_props_extension doesn't complies with the Mapping protocol. `DatabaseBackend` will make use of `get_task_props_extension` to update a potential custom model with the custom properties --- Resolves celery#305 Fixes celery#314
diegocastrum
pushed a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 17, 2022
`models` module replaced by a `models` package containing an `abstract` module (for abstract models) and a `generic` module (for the default models, previously in the `models` module) --- Resolves celery#305 Fixes celery#314
diegocastrum
pushed a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 17, 2022
… module. Added some minor changes. --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 17, 2022
Added a `helpers` module into `models` containing the functions
`taskresult_model()` and `groupresult_model()`.
* `taskresult_model()`: will try to find the custom model using a
dotted path defined under the constant
`CELERY_RESULTS_TASKRESULT_MODEL` in the settings of the user's project
* `groupresult_model()` will try to do the same using under the
constant `CELERY_RESULTS_GROUPRESULT_MODEL`.
By default if these attributes are not found `django-celery-results`
will use the default models (`models.TaskResult` and
`models.GroupResult`).
Updated database backend in order to use custom models for `TaskResult
and `GroupResult` it they're present.
Instead to import explicitely the `TaskResult` and the `GroupResult`
(default models from `django-celery-results`) we make use of the model
helpers to load the right classes, the custom ones if they're present
otherwise we use the default ones.
Getting data from `task_kwargs` to extend the `task_properties` and be
able to store them into the database (using the custom models).
First of all we need a way to get data from `task_kwargs` (or somewhere
else) just before a `task_result` record is created, evaluate that data
and find the right values that will be used to fill the new fields
defined in the custom model.
So for this purpose we added a settings module to
`django-celery-results` which will hold default settings, the first
setting that will contain is a function in charge to get a callback from
the settings of the user project. This callback will be feeded by the
task `task_kwargs`, which will be intercepted in
`DatabaseBackend._get_extended_properties` just before the `task_kwargs`
are encoded by `encode_content()` method and send it to the
`store_result` method from the object manager of `TaskModel`
(Custom/Default one).
To end, we must to extend the arguments of the `store_result` method
from the `TaskResult` Manager adding `**extra_fields` that will make us
able to send extra data to the custom model, when it's defined.
---
Resolves celery#305
Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 17, 2022
`extend_task_props_callback` moved from `_get_extended_properties` to `_store_result`. Suggested by @AllesVeldman. `extend_task_props_callback` will get the `request` object as first parameter and a copy of `task_props` (avoiding potential manipulation of the original `task_props`) as second paramenter. --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 17, 2022
`get_callback_function()` gets a default callback as an arg returning explicitely an empty dict. `get_callback_function()` raises an `ImproperlyConfigured` exception when the callback is not callable. --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Aug 17, 2022
Added `get_task_props_extension` to `settings` module which will raise an `ImproperlyConfigured` when the task_props_extension doesn't complies with the Mapping protocol. `DatabaseBackend` will make use of `get_task_props_extension` to update a potential custom model with the custom properties --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 13, 2022
A new page added to the documentation where we explain how to use this feature. -- issue: celery#305 pull-request: celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 13, 2022
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 21, 2024
- Added new abstract model `AbstractChordCounter` in `abstract.py` for Chord synchronization, including fields for `group_id`, `sub_tasks`, and `count`. - Updated `ChordCounter` model in `generic.py` to inherit from `AbstractChordCounter`. - Moved `group_result` method from `ChordCounter` to `AbstractChordCounter`. - Added helper function `chordcounter_model` in `helpers.py` to return the active `ChordCounter` model. - Updated import statements in `database.py` to use `chordcounter_model` helper function. - Added `ChordCounterModel` attribute to `DatabaseBackend` class, and updated `create` and `get` methods to use `ChordCounterModel` instead of `ChordCounter`. Relates to: celery#305
diegocastrum
pushed a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 29, 2024
`models` module replaced by a `models` package containing an `abstract` module (for abstract models) and a `generic` module (for the default models, previously in the `models` module) --- Resolves celery#305 Fixes celery#314
diegocastrum
pushed a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 29, 2024
… module. Added some minor changes. --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 29, 2024
Added a `helpers` module into `models` containing the functions
`taskresult_model()` and `groupresult_model()`.
* `taskresult_model()`: will try to find the custom model using a
dotted path defined under the constant
`CELERY_RESULTS_TASKRESULT_MODEL` in the settings of the user's project
* `groupresult_model()` will try to do the same using under the
constant `CELERY_RESULTS_GROUPRESULT_MODEL`.
By default if these attributes are not found `django-celery-results`
will use the default models (`models.TaskResult` and
`models.GroupResult`).
Updated database backend in order to use custom models for `TaskResult
and `GroupResult` it they're present.
Instead to import explicitely the `TaskResult` and the `GroupResult`
(default models from `django-celery-results`) we make use of the model
helpers to load the right classes, the custom ones if they're present
otherwise we use the default ones.
Getting data from `task_kwargs` to extend the `task_properties` and be
able to store them into the database (using the custom models).
First of all we need a way to get data from `task_kwargs` (or somewhere
else) just before a `task_result` record is created, evaluate that data
and find the right values that will be used to fill the new fields
defined in the custom model.
So for this purpose we added a settings module to
`django-celery-results` which will hold default settings, the first
setting that will contain is a function in charge to get a callback from
the settings of the user project. This callback will be feeded by the
task `task_kwargs`, which will be intercepted in
`DatabaseBackend._get_extended_properties` just before the `task_kwargs`
are encoded by `encode_content()` method and send it to the
`store_result` method from the object manager of `TaskModel`
(Custom/Default one).
To end, we must to extend the arguments of the `store_result` method
from the `TaskResult` Manager adding `extra_fields` argument that will
make us able to send extra data to the custom model, when it's defined.
---
Resolves celery#305
Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 29, 2024
`extend_task_props_callback` moved from `_get_extended_properties` to `_store_result`. Suggested by @AllesVeldman. `extend_task_props_callback` will get the `request` object as first parameter and a copy of `task_props` (avoiding potential manipulation of the original `task_props`) as second paramenter. --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 29, 2024
`get_callback_function()` gets a default callback as an arg returning explicitely an empty dict. `get_callback_function()` raises an `ImproperlyConfigured` exception when the callback is not callable. --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 29, 2024
Added `get_task_props_extension` to `settings` module which will raise an `ImproperlyConfigured` when the task_props_extension doesn't complies with the Mapping protocol. `DatabaseBackend` will make use of `get_task_props_extension` to update a potential custom model with the custom properties --- Resolves celery#305 Fixes celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 29, 2024
A new page added to the documentation where we explain how to use this feature. -- issue: celery#305 pull-request: celery#314
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 29, 2024
diegocastrum
added a commit
to jose-padin/django-celery-results
that referenced
this issue
Oct 29, 2024
- Added new abstract model `AbstractChordCounter` in `abstract.py` for Chord synchronization, including fields for `group_id`, `sub_tasks`, and `count`. - Updated `ChordCounter` model in `generic.py` to inherit from `AbstractChordCounter`. - Moved `group_result` method from `ChordCounter` to `AbstractChordCounter`. - Added helper function `chordcounter_model` in `helpers.py` to return the active `ChordCounter` model. - Updated import statements in `database.py` to use `chordcounter_model` helper function. - Added `ChordCounterModel` attribute to `DatabaseBackend` class, and updated `create` and `get` methods to use `ChordCounterModel` instead of `ChordCounter`. Relates to: celery#305
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Originally posted by @auvipy in #46 (comment)
Adding abstract base models will make the base models more extendable in projects where extra fields are needed.
The text was updated successfully, but these errors were encountered: