Skip to content
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

CrontabSchedule uniqueness #701

Open
sevdog opened this issue Dec 18, 2023 · 3 comments
Open

CrontabSchedule uniqueness #701

sevdog opened this issue Dec 18, 2023 · 3 comments

Comments

@sevdog
Copy link

sevdog commented Dec 18, 2023

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
Copy link

ulgens commented Feb 27, 2024

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
Copy link
Author

sevdog commented Mar 1, 2024

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
Copy link

giolucasd commented May 7, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants