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
Uh oh!
There was an error while loading. Please reload this page.
-
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