-
Notifications
You must be signed in to change notification settings - Fork 20
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
Use cache backend to store tqdm process information #58
Conversation
_huey_signals.SIGNAL_EXPIRED, | ||
_huey_signals.SIGNAL_REVOKED, | ||
_huey_signals.SIGNAL_INTERRUPTED, | ||
) |
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.
I am not sure if this information is completely correct.
7b13f6d
to
2d8d3bd
Compare
2d8d3bd
to
122439e
Compare
Remove the `TaskProgressModel` model that was used to store process information. But this has some disadvantages: * Every `process_info.update()` call creates one `TaskProgressModel` instance and this model was never cleaned. So if many items was processed, the table may be get full. So this PR fixed #46 * If many small `process_info.update()` calls happens, then we get a high database load Refactor that completely by using the Django cache to store progress information. If a task has been finished: Transfer the information from cache to database.
122439e
to
e7e5d1d
Compare
Hi Jedie, any news on this? Because I just realized that you closed issue #46 while my solution is not implemented While I didn't had this problem anymore since August 22 with the fix I implemented locally(see #46), The code that has been working without any issue in prod since August 22, 2021:
I'll create a PR to speed-up the process |
@Skrattoune Your idea is used here: #68 Any comments on code change here?!? |
Remove the
TaskProgressModel
model that was used to store process information. But this has somedisadvantages:
process_info.update()
call creates oneTaskProgressModel
instance and this model wasnever cleaned. So if many items was processed, the table may be get full. So this PR fixed django.db.utils.OperationalError: (1114, "The table 'huey_monitor_taskprogressmodel' is full") #46
process_info.update()
calls happens, then we get a high database loadRefactor that completely by using the Django cache to store progress information.
If a task has been finished: Transfer the information from cache to database.