The reason for adding this level of indirection is a way to deal with the "limitations" of JobRubr when it comes to serialization (i.e. default ctor needed and standard jackson strategies apply) and upcasting. Thus, when using "Reminders", you could register a dispatcher fn instead:
where type constructs a Predicate that matches the type of the "reminder" document.
Alternately, or you could refactor to use "commands" that are serializable and just use JobRunR directly.
Alt 2: Never remove methods until all old jobs are removed. Set old method to package private and deprecated and make it forward to new method.
db-scheduler, quartz, spring batch, jobrunr.
Ex jobrunr, create a generic fn Reminders.apply(Reminder) where
Reminderis something like this:where
datais optional.The reason for adding this level of indirection is a way to deal with the "limitations" of JobRubr when it comes to serialization (i.e. default ctor needed and standard jackson strategies apply) and upcasting. Thus, when using "Reminders", you could register a dispatcher fn instead:
where
typeconstructs aPredicatethat matches the type of the "reminder" document.Alternately, or you could refactor to use "commands" that are serializable and just use JobRunR directly. Alt 2: Never remove methods until all old jobs are removed. Set old method to package private and deprecated and make it forward to new method.