CrontabSchedule uniqueness

[sevdog]

Summary:

To avoid accidental replication it would be nice to have a UniqueConstraint on CrontabSchedule model.

Detailed information

As matter of fact every row in the CrontabSchedule table should be unique, without any check nor constraints it may cause confusion to whoever admins the scheduler.

This may cause a breaking change if any foreign-key to CrontabSchedule is defined outside of this app. Inside the app it can be handled with an appropriate data-migration which detectes duplicates and fixes them before enforcing the unique constraint.

[ulgens]

Which field do you think should be unique? I think being able to create "duplicate" schedules is actually a feature; one may want to use the same value/content on different PeriodicTask without referring to the same object multiple times, which gives some sort of context isolation between periodic task instances.

[sevdog]

Technically the tuple composed by every fields (except PK) in CrontabSchedule should be unique, if you want to use that table to be clear and have the minimun number of records.

I understand the point in "keeping a custom schedule for each task", but in that way the meaning of a dedicated table for each kind of schedule just provide a small validation on input format which could be easily replicated at validation level, thus not requiring a table on DB but just an appropriated field.

IMO it makes sense to have some checks at database level to avoid data duplication. If the requirement of data duplication for management exists then it should be configurable to have or not unique constraints on those tables.

[giolucasd]

I support sevdog point of view and I would be willing to submit the PR.

[auvipy]

I support sevdog point of view and I would be willing to submit the PR.

you can come with a draft PR