You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Often there are scenarios where a task is queued but due to external changes (user changing their notification settings for example.) the task execution date needs to be changed.
There a 2 ways of handling this:
Just remove the old task and replace it with the new task.
Update the existing task with a new execution date.
I opt for option 2 since it's more efficient and can be done in a single query (findAndModify) vs a delete and insert query.
Currently there is no good API for handling this so we have to resort to using code like this
letdocument=tryawait context.mongodb["queue"].find(...)// find a scheduled Task
if let metadata =document["metadata"]as?Document,let reminderDate =metadata["reminder_date"]as?Date,let id =document["_id"]as?ObjectId{letnewDate= reminderDate.addingTimeInterval(....)
_ =tryawait context.mongodb["queue"].findAndModify(where:["_id": id],
update:["$set":["configuration.scheduledDate": newDate]asDocument]).execute()}
Also there is some slight discrepancy/redundancy for execution dates. In the screenshot attached there are 3 separate date fields that represent when a task should be executed.
But the one that really matters is the configuration.scheduledDate. There is a caveat that the metadata.taskExecutionDate is derived from conforming to the ScheduledTask but that value is actually never read when it's time to execute but it's rather used to create the configuration.scheduledDate. Maybe we don't have to save it to take up extra space but decoding would fail since we have to specify it anyway another problem for another day.
Also maxTaskDuration is also duplicated when it doesn't necessarily have to be.
As far as a better API maybe there could be a function on the context that can be
I agree that we could use better APIs, but not in the proposed way. I also don't think the duplication is an issue in MongoQueue.
executeAfter is the date at which it can be executed at the earliest.
configuration.scheduledDate is an internal piece of state, derived from your metadata. And is used to reproduce a task's state. It is known to be a scheduled one-off task, based on the configurationType. But could be recurring, and has a completely different format if it is not a scheduled (one-off) task. Therefore, you cannot rely on configuration.scheduledDate for queries.
metadata.taskExecutionDate is your code. It's stored, because it's not a computed property. But it's not a reliable field, therefore it cannot be queried.
metadata.maxTaskDuration is the same story,as you made it a stored property. But it can be computed, thus cannot be queried.
While I acknowledge people tend to make it stored, I don't want to rely on that assumption.
And I like providing the liberty not to
Often there are scenarios where a task is queued but due to external changes (user changing their notification settings for example.) the task execution date needs to be changed.
There a 2 ways of handling this:
I opt for option 2 since it's more efficient and can be done in a single query (
findAndModify
) vs a delete and insert query.Currently there is no good API for handling this so we have to resort to using code like this
Also there is some slight discrepancy/redundancy for execution dates. In the screenshot attached there are 3 separate date fields that represent when a task should be executed.
But the one that really matters is the
configuration.scheduledDate
. There is a caveat that themetadata.taskExecutionDate
is derived from conforming to theScheduledTask
but that value is actually never read when it's time to execute but it's rather used to create theconfiguration.scheduledDate
. Maybe we don't have to save it to take up extra space but decoding would fail since we have to specify it anyway another problem for another day.Also
maxTaskDuration
is also duplicated when it doesn't necessarily have to be.As far as a better API maybe there could be a function on the context that can be
The text was updated successfully, but these errors were encountered: