-
-
Notifications
You must be signed in to change notification settings - Fork 464
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
Sending create_historical_record() to celery tasks #1331
Comments
I have no experience with Celery, but simply overriding from typing import override
from django.db import models
from simple_history.models import HistoricalRecords
class HistoricalRecordsWithCelery(HistoricalRecords):
@override # If using Python >= 3.12
def create_historical_record(self, instance, history_type, using=None):
# custom code (invoking Celery?)
class YourHistoryTrackedModel(models.Model):
...
history = HistoricalRecordsWithCelery() Does that work for you? 🙂 |
@ddabble thank you for the speedy response! My project is currently on Python 3.10, so I'm not sure if
|
I tested out something similar to this solution in my apps.py, which worked for me when testing:
This overrides the |
Yeah,
Could you help me understand how that would happen? 🤔 Because I would instead describe
I'm not sure I understand how you're getting that error; could you provide a minimally reproducible example?
Sure, that could also work :) Though there are reasons monkey-patching is generally regarded as a last resort, some of which include that it might produce unexpected side effects (to developers who are not aware that it was monkey-patched) and hard-to-trace errors, and that it's often much less flexible compared to "proper" solutions - which I think would be class inheritance, in this case. |
yes for sure! Here's what I tried doing, which resulted in class ExtraHistoricalClaimFieldsModel(models.Model):
backend_path = models.CharField(
max_length=200, blank=True, null=True, default=None
)
class Meta:
abstract = True
class HistoricalBaseModel(HistoricalRecords(use_base_model_db=False, history_user_id_field=models.IntegerField(null=True), bases=[ExtraHistoricalClaimFieldsModel, ])):
def create_historical_record(self, instance, history_type, using=None):
# call create_historical_record.delay()
return "saved"
class YourHistoryTrackedModel(models.Model):
...
history = HistoricalBaseModel() But I think your right, monkey patching should be used as a last resort since it would definitely be harder to debug |
Ah, I think I see what you're trying to do 😅 The class list inside the parentheses after a class name (i.e. class ExtraHistoricalClaimFieldsModel(models.Model):
backend_path = models.CharField(
max_length=200, blank=True, null=True, default=None
)
class Meta:
abstract = True
class CustomHistoricalRecords(HistoricalRecords):
def create_historical_record(self, instance, history_type, using=None):
# call create_historical_record.delay()
return "saved"
class YourHistoryTrackedModel(models.Model):
...
history = CustomHistoricalRecords(use_base_model_db=False, history_user_id_field=models.IntegerField(null=True), bases=[ExtraHistoricalClaimFieldsModel, ]) Does that make sense? 🙂 |
ahhh yay that worked! 🥳 makes sense that I should be putting the constructors in the constructor method instead of where the class is being inherited. thanks for the help :) |
Alright nice, no problem :) Closing, now that the issue seems resolved. |
Problem Statement
To minimize performance concerns, I want to send
create_historical_record()
as a celery task. This way we can easily handle one-off scripts that update a bunch of records, as well as avoiding database overloading if there's a bunch of historical records trying to be created and the db is locked.I was reading up on this thread, which suggests that we can override the
create_historical_record
and create a custom method that is sent to celery. How would we go about overriding this method?Describe the solution you'd like
A relatively straightforward solution to overriding the create_historical_record so we can send it as a job, instead of writing to the db at runtime
Describe alternatives you've considered
I've read about monkey patching, which would be instantiating the customized create_historical_record() at runtime and overriding the original method.
The text was updated successfully, but these errors were encountered: