tejasjadhav / django-scheduler Goto Github PK

I've got a celery worker running with RabbitMQ and have been able to test with celery-beat that the tasks will run using periodic tasks and intervals as well as crontabs. I don't want to use those because rrule is so much nicer.

The Task is being created as far as I can tell in the database.

task_id = TaskScheduler.schedule(say_hello, description="finally", rrule_string='RRULE:FREQ=HOURLY;INTERVAL=2')

And here's the task:

@shared_task(base=RepeatTask, name='say_hello')
def say_hello():
    print("sayingHello")

Any ideas why this might not be picking it up?

Currently, args and kwargs of the scheduled tasks are stored in JSONField which has support only for PostgreSQL databases.

Suggestion

We can use a TextField instead and use json.loads and json.dumps to fetch and store the function arguments respectively.

It would be much convenient to change the scheduled date and time of an already scheduled task. This means, if a task is about to run at a specified date and time, then there should be some way to change this and schedule it at some other time. It can be preponed or postponed.

Also, changing the recurrence rule would affect all the subsequent runs and the updated recurrence rule would be in effect.

I need to add a set of exhaustive test cases for this library. Test cases should cover only library specific edge cases.

The current logic for calculating the next ETA is not a clean solution. To calculate the next ETA, it runs the recurrence rule from start, iterates every single outcome and then matches the one which is greater than the current ETA.

This might not be a big problem if the intervals are very long. For example, if the interval is one month, and we want to calculate the next ETA after 6 months, then there would be 6 iterations before getting the right ETA.

However, if the interval is small (one second) and now if we want to calculate next ETA after 6 months, then there would be 60 (seconds) * 60 (minutes) * 24 (hours) * 30 (days) * 6 (months) = 15552000 iterations! This is very inefficient.

Possible workaround

I think we can re-implement custom recurrence rule sequence generator which efficiently calculates the next ETA (using mathematics, maybe 😛). This might free us from dependency on dateutil (nothing against the library, it's awesome!).

Need to add a basic setup and installation guide in the README which includes,

• pip installation.
• Django setup.
• Celery worker setup for basic run.