Add pagination to JobModel ListView in Quartz Addon in Jmix 2.x

Ideas
#1

Hi Jmix team! :wave:

First of all, thank you for the great work you’re doing on the platform — it keeps getting better and more powerful! :rocket:

I was wondering if pagination for the Quartz add-on (in job-model-list-view.xml) is something that might be considered for the roadmap. It would really help with scalability on the /quartz/jobmodels page, especially in environments where a large number of jobs have been executed and the list grows quite big.

Additionally, would it be possible to introduce a generic “retention” job implementation? The idea would be to periodically clean up configured “old” entities based on a SpEL condition (for example using creationDate or a similar field). This could potentially be applied to Quartz job models as well, even though they are not standard Jmix entities.

I think this could be a useful built-in mechanism for keeping datasets lean over time and reducing manual maintenance.

Thanks in advance for your feedback, and keep up the amazing work! :blush:

Best regards,
Ale

#3

Hi Alessandro,

Thanks for your suggestions.

Pagination

The current issue is that Quartz doesn’t have pagination API. And using direct access to Quartz table without Quartz API doesn’t look like a good idea for now.
A possible minimal solution is to create a “fake” pagination - internally it will still load all jobs, but render them as multiple pages.

Do you need jobs pagination just for UX improvement or you have some performance issues with that list because of large amount of jobs? How many jobs do you have (scale)?

Retention Job

Did you mean to implement some OOB job class with logic to remove another jobs specifically? Or some general logic to remove any entities by provided condition?

If it’s the latter - it’s not a good idea. To “dangerous”, to many possible details. Different entities can have different management approaches. I don’t see how we can generalize it. Project side is responsible for project entities.

If we talk about Jobs only - can you provide actual scenarios you want to have (if you have some)?

In theory it’s possible to apply SpEL to Job model, but maybe it’s better to provide only predefined conditions, not the “full” control. Any of that can be provided as a Job parameters. Need to review.

Both features have a chance to be implemented (the second one - less likely), but I can’t give any timeline.

Regards,
Ivan

#4

Thanks for the reply! :blush:

Regarding the pagination, it’s a matter of performance, since we are currently handling a lot of async processes via cronJobs. :gear: I ended up wrapping the QuartzService in a new one annotated with @Primary in order to override the main methods for job creation, updates, pausing, execution, etc., and adding custom logic that basically creates a new QuartzJobInfo entity for each job managed by Quartz itself. :hammer_and_wrench:

In this way, my single point of access to Quartz jobs is a new ListView on the QuartzJobInfo entity, easily handling pagination and bulk actions as well as execution/pause/resume/edit standard actions, which calls the standard Jmix actions or detail views. :bar_chart:

Regarding the Retention Job, I was thinking about a very generic job for both jobs and entities. The core idea would be to create a CronJob that has this standard OOTB job class implementation (i.e., org.jmix.jobs.RetentionJob.class) and use a set of JobParameters in order to handle the retention of custom entities. :broom:

I know it could be dangerous, but in any case, it is something used by administrators to handle maintenance stuff, so it must be something that is configured and controlled, not something that is “active” by default. :warning:

And maybe with parameters, we can specify other stuff like attributes to be evaluated for the retention (modifiedDate / creationDate / status / etc.) or a custom approach providing a parameter with a springBeanName referring to a class implementing a dedicated evaluator for retention. :bulb:

It would be interesting to see how you, as the platform developers, would approach this type of massive deletion. :face_with_monocle:

Thanks a lot,
Regards
Ale