Replies: 2 comments
-
Ok, no matter. "known_tasks" at scheduler create time. I'll see if that works. |
Beta Was this translation helpful? Give feedback.
0 replies
-
As you say there a probably a couple of ways to work around this limitation. One way would be somethink like this example: https://github.com/kagkarlsson/db-scheduler/blob/master/examples/features/src/main/java/com/github/kagkarlsson/examples/RecurringTaskWithPersistentScheduleMain.java One of the goals of db-scheduler is simplicity also in the data-model, making me quite reluctant to adding more tables to the model :) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
My example here is Quartz. There you have a Job (task) and a Trigger. These two things are are distinct. The Job is only what to do, the Trigger is when and how it gets fired.
Is it possible in a future versions to separate these two? For example I have a single Task which I would like have fired in differing ways and with differing data. I know there are code workaround, but having this split capability would remove a lot of complexity in the code.
I know this may need to go to two table instead of one. But I'd be fine with that. I have flyway managing that anyway.
Beta Was this translation helpful? Give feedback.
All reactions