Get all triggers in Quartz.NET

Question

I need to retrieve a list of all triggers in a Quartz.NET database so I can list information about them in a table. I want all triggers, regardless of whether they're running, waiting, acquired, or whatever. I'm only using a single scheduler name and a single group, so in my case this is basically a simple matter of doing SELECT * FROM QRTZ_TRIGGERS (not entirely true because I also need information from the QRTZ_CRON_TRIGGERS table), but I'd rather go through the API.

Currently I'm going through all known job types and calling GetTriggersOfJob for each one, as I've seen recommended in a couple of places on the internet. My real code is more complex than this, but this is the gist of it:

var allJobKeys = *a list of all known jobs*
var scheduler = *a new scheduler object*
var allTriggers = allJobKeys
    .Select(scheduler.GetTriggersOfJob)
    .ToList();

Is this really the only way to do it? It's really inefficient! I have about 30 different job types (and counting), most of which are likely to have zero triggers associated with them at any given time. But this will require 30 database queries every time, instead of a single query that retrieves all of them.

Note that the scheduler I'm retrieving the triggers in is used solely for that purpose as well as for creating/updating/deleting triggers, and will never be used to execute jobs. I ensure that by never calling scheduler.Start() on it.

From what I can tell there's no getAllTriggers() in the original Quartz API in Java either, so I'm assuming there's a reason why this doesn't exist, even though it seems like such a no-brainer. Is it do with concurrency handling when there are multiple scheduler hosts running in clustered mode or something like that? It seems like something people would want to do fairly often.

Answer 1

A little more straightforward way could be

var allTriggerKeys = sched.GetTriggerKeys(GroupMatcher<TriggerKey>.AnyGroup());
foreach (var triggerKey in allTriggerKeys)
{
    ITrigger trigger = sched.GetTrigger(triggerKey);
}

Why so complicated and slow? The thing here is that there is trigger polymorphism and the type (and thus the associated data via linked table) is not known beforehand. After base record is loaded the rest of data can be loaded. And yes, the API was not originally meant for set operations.

If you are just reporting, I'd say bite the bullet and create the custom SQL query with (outer) joins etc. Just don't update Quartz's tables without Quartz knowing about it. Also don't issue DB locks. Prepare to fix the the query if schema changes.