Scheduled task name behaviour inconsistent

[ad-65]

I've been using django-q for a while now and it is working great. Celery was overkill for me and I really like how django-q can use the orm as a broker.

When creating scheduled tasks sometimes I create them directly using Schedule.objects.create() and sometimes by using the schedule() helper function. I have found it useful to create these tasks with the same name so I can find them by group in the successful/failed model in the django admin. The problem is that sometimes there can be multiple schedules with the same name at the same time.

• When creating the schedule objects directly the name can be the same, but when using the helper function an exception is raised due to a unique check in that function.
• The name is not required according to the docs or the model, but it is a required field in the admin. This makes it hard to edit nameless jobs.

I probably don't understand the reasons for this behaviour but why not go one way or the other?

• Make the name field required/unique, and add a group field to the Schedule model so the group can be specified instead of using the name or the pk.

-or-

• Allow nulls in the name field, remove the duplicate check in the helper function, and remove the required check in the django admin.

Either of these would keep the instance, helper function, and admin behaviour consistent. As it stands right now I had to change my code to create the Schedule objects directly so I don't get an IntegrityError and can still filter my successful/failed tasks by group.

Thanks.

[Koed00]

For now you can just add group='schedule_group' to the schedules Kwargs field to group your schedule result. You can in fact add any of the task options there.
If for some reason you are using an argument named 'group' in your scheduled function, you can instead add q_options={'group': 'schedule_group'} to the kwargs.
I'll have a look at why the name field is inconsistent like this. I might have had a reason for it, it might have just happened.

[ad-65]

Thanks for the response, I just tried it out.

I am using the 0.7.15 release and this will still result in a group named after the schedules pk:

scheduled_reminder = schedule("myapp.apps.core.tasks.send_reminder",
                               recipients,
                               subject,
                               body,
                               schedule_type=Schedule.ONCE,
                               next_run=mydatetime,
                               q_options={"group": "reminder_group_name"},
                               html=True)

It looks like cluster.scheduler() always overwrites the group keyword in q_options.

...
q_options = kwargs.get('q_options', {})
...
# send it to the cluster
q_options['broker'] = broker
q_options['group'] = s.name or s.id
kwargs['q_options'] = q_options
s.task = tasks.async(s.func, *args, **kwargs)
...

In this case the group keyword just gets passed to send_reminder, causing an exception if it doesn't expect a keyword by that name.

scheduled_reminder = schedule("myapp.apps.core.tasks.send_reminder",
                               recipients,
                               subject,
                               body,
                               schedule_type=Schedule.ONCE,
                               next_run=mydatetime,
                               group="reminder_group_name",
                               html=True)

I may have misunderstood the suggestion?

Thanks again.

[Koed00]

Nope you did not misunderstand. This is just me regretting answering this stuff late at night after a 12 hour shift 👍
I'll see what I can about this. It's actually something I use myself.

[Koed00]

The current version allows for blank schedule names in the admin.
You can now also override the group name of the schedule via the q_options dict.
I have to test it a bit, but it should go in with the next release.

[ad-65]

Cool, that should do the trick.

Without the DB unique constraint on the schedule name people could still do:

scheduled_reminder = schedule("myapp.apps.core.tasks.send_reminder",
                               recipients,
                               subject,
                               body,
                               schedule_type=Schedule.ONCE,
                               next_run=mydatetime,
                               html=True)
scheduled_reminder.name = "non-unique name"
scheduled_reminder.save()

Which is actually what I am doing temporarily until he next release. If this isn't a problem then we are good to go.

Thanks.