CanopyLabs.Quartz.EntityFrameworkCore.PostgreSQL 4.3.0

CanopyLabs.Quartz.EntityFrameworkCore.PostgreSQL

EF Core migration support for Quartz.NET PostgreSQL tables.

Instead of running raw SQL scripts to create Quartz.NET's database tables, this library lets them participate in your EF Core migrations.

Installation

dotnet add package CanopyLabs.Quartz.EntityFrameworkCore.PostgreSQL

Usage

In your DbContext.OnModelCreating:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // Add Quartz.NET tables with default settings (qrtz_ prefix, public schema)
    modelBuilder.AddQuartzPostgreSql();
}

Then generate a migration:

dotnet ef migrations add AddQuartzTables
dotnet ef database update

Custom Schema

modelBuilder.AddQuartzPostgreSql(schema: "quartz");

When using a custom schema, configure Quartz.NET's table prefix to match:

var properties = new NameValueCollection
{
    ["quartz.jobStore.tablePrefix"] = "quartz.qrtz_"
};

Custom Prefix

modelBuilder.AddQuartzPostgreSql(prefix: "myapp_qrtz_", schema: "quartz");

Version Compatibility

Match the major.minor version of this package to your Quartz.NET version.

A newer package works with an older Quartz.NET; the reverse does not. Every column added so far is nullable or defaulted, and Quartz.NET 3.18+ probes for the columns it needs rather than requiring them, so a column a given Quartz.NET version does not know about is simply unused.

Quartz.NET 4.0 makes the reverse direction fail loudly. It removed those probes, assumes misfire_orig_fire_time, execution_group, preferred_node and preferred_node_auto all exist, and validates its schema at startup. A 3.x-era package under a 4.x scheduler no longer degrades quietly — it stops the scheduler.

3.19.x added three columns on top of 3.17.x:

Upgrading from the 3.17.x package generates a migration that adds these columns. All three are nullable or defaulted, so the migration is safe to apply to a live scheduler before rolling out the matching Quartz.NET upgrade.

3.20.x realigns the indexes

3.20.0 changes no table and no column. It tracks Quartz.NET 3.20.0's PostgreSQL index realignment: every index now leads with sched_name, which every AdoJobStore statement filters on first, and idx_qrtz_t_nft_st gets its columns in acquire-query order (sched_name, trigger_state, next_fire_time) instead of the reversed next_fire_time, trigger_state. Eleven indexes become ten — seven single-column indexes that no statement could drive a scan from are replaced by five composites.

Upgrading from the 3.19.x package generates a migration that drops the old indexes and creates the new ones. Two things worth knowing before applying it:

• It is performance-only. Quartz.NET never names an index, so nothing breaks on any version if you skip it, and a 3.20.x package is safe against a 3.18.x or 3.19.x scheduler.
• On a busy database, hand-edit the generated migration to use CREATE INDEX CONCURRENTLY / DROP INDEX CONCURRENTLY and run those statements outside a transaction. EF Core wraps a migration in one by default, and neither concurrent form can run inside a transaction block.

4.0.x tracks the Quartz.NET 4.0 schema

4.0.0 is the first release to add a table. It tracks Quartz.NET 4.0's mandatory migration:

Both new columns are nullable with no default, so every existing row reads as "no retry policy" and no data migration is needed. Upgrading from the 3.20.x package generates a migration that adds the table and columns and reshapes the indexes.

Two things worth knowing before applying it:

• The column half is safe during a rolling upgrade; the index half is not. Upstream ships these as two scripts for that reason. The generated EF migration combines them. If you are rolling 3.x and 4.x nodes side by side, split the generated migration and hold the index statements back until the last 3.x node is down.
• On a busy database, hand-edit the generated migration to use CREATE INDEX CONCURRENTLY / DROP INDEX CONCURRENTLY and run those statements outside a transaction. EF Core wraps a migration in one by default, and neither concurrent form can run inside a transaction block.

4.2.x tracks the Quartz.NET 4.2 schema

Quartz.NET 4.1 changed no table, so there is no 4.1.x package: 4.0.x covers 4.1.x. 4.2.0 adds three columns and two tables, taken from upstream's two 4.2 migrations:

A 4.2 scheduler refuses to start without the three continuation columns. It validates its schema at startup, so a 4.0.x package under Quartz.NET 4.2 stops the scheduler with column "continues_trigger_name" does not exist.

Upgrading from the 4.0.x package generates a migration that adds the columns, the two tables and their indexes. It is safe to apply before rolling out Quartz.NET 4.2:

• The three columns are nullable with no default, so existing rows need no data migration, and 4.0/4.1 nodes never read them. Migrate, roll every node to 4.2, and only then schedule continuations, since a 4.0 or 4.1 node cannot settle one.
• The history tables have no foreign keys and nothing else references them, so they are inert until a 4.2 node turns the history on.

4.3.x tracks the Quartz.NET 4.3 schema

4.3.0 adds columns only: no table and no index changes. It follows upstream's five 4.3 migrations:

A 4.3 scheduler refuses to start without the required columns, so a 4.2.x package under Quartz.NET 4.3 stops the scheduler.

Upgrading from the 4.2.x package generates a migration that only adds nullable columns with no default. Existing rows need no data migration, and 4.0 to 4.2 nodes never read the new columns, so it is safe to apply before rolling out Quartz.NET 4.3.

License

MIT - see LICENSE for details.

Copyright (c) Canopy Labs