The Quartz.Weasel packages put the ADO.NET job store's tables under Weasel, the schema tool behind Marten and Wolverine. An application already on that stack then creates and migrates Quartz's tables with the workflow it runs for its own: db-apply, db-assert, db-patch, resources setup, and AutoCreate at startup. Requires Quartz 4.3 or later; 4.4 for MySQL, Oracle and Firebird.

An application not using Weasel keeps ProvisionSchema() and the scripts under database/migrations/.

Packages

An application beside Marten or Wolverine resolves both at least that high.

dotnet add package Quartz.Weasel.PostgreSQL

Registering

Call the dialect's method on the same store that chose the database:

HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);

builder.Services.AddQuartz(q => q.UsePersistentStore(store =>
{
    store.UsePostgres(connectionString);
    store.UseSystemTextJsonSerializer();
    store.UseWeaselForPostgres();
}));
builder.Services.AddQuartzHostedService();

IHost host = builder.Build();

// db-apply, db-assert, db-patch, resources: JasperFx's command line, over this host
return await host.RunJasperFxCommands(args);

services.AddQuartz(q => q.UsePersistentStore(store =>
{
    store.UseSqlServer(connectionString);
    store.UseWeaselForSqlServer();
}));

services.AddQuartz(q => q.UsePersistentStore(store =>
{
    store.UseMySqlConnector(connectionString);
    store.UseWeaselForMySql();
}));

services.AddQuartz(q => q.UsePersistentStore(store =>
{
    store.UseOracle(connectionString);
    store.UseWeaselForOracle();
}));

services.AddQuartz(q => q.UsePersistentStore(store =>
{
    store.UseFirebird(connectionString);
    store.UseWeaselForFirebird();
}));

services.AddQuartz(q => q.UsePersistentStore(store =>
{
    store.UseSqlite(connectionString);
    store.UseWeaselForSqlite();
}));

The dialect is in the method name, so an application with several packages never has an ambiguous call.

Checked at startup:

• The store's driver matches the package: Npgsql for PostgreSQL, Microsoft.Data.SqlClient for SQL Server, MySqlConnector for MySQL (UseMySqlConnector, not UseMySql), Oracle.ManagedDataAccess for Oracle, FirebirdSql.Data.FirebirdClient for Firebird, Microsoft.Data.Sqlite for SQLite.
• The store does not also call ProvisionSchema(). A schema has one owner.

Each scheduler is one Weasel database. Its identifier is the scheduler name and its subject URI is quartz://scheduler/<name>, so db-patch -d <name> picks it. Weasel connects through the store's own connection provider.

Startup

The schema is applied before any scheduler is built, so the store's validation sees the result.

None applies nothing at startup; the store's validation then reports anything missing. To apply at deploy time only:

// Weasel applies nothing at startup in Production; db-apply does it at deploy time instead.
services.AddJasperFx(options => options.Production.ResourceAutoCreate = AutoCreate.None);

A failed apply fails the startup, unless the profile's ResourceMigrationFailureMode is ContinueOnFailures: then it is logged (event 10003) and the store's validation decides.

Commands

With the host's Main ending in await host.RunJasperFxCommands(args):

resources clear and resources teardown do nothing to Quartz's tables: they hold the schedule, not state that can be rebuilt.

What Weasel changes

The model is generated from the same source as the store's own scripts, and names every object the way the database's catalog does. A database created by database/tables/, by ProvisionSchema() or by the migrations therefore reads as unchanged. The execution history tables and QRTZ_JOB_STATUS are always part of it, as they are of a fresh install.

On a 4.3 database an apply only adds: five nullable columns and IDX_QRTZ_EH_JOB_TIME on QRTZ_EXECUTION_HISTORY, and the QRTZ_JOB_STATUS table. Nothing is rebuilt.

PostgreSQL

The schema is the table prefix's: quartz.qrtz_ puts the tables in schema quartz. Without one it is public.

// tables quartz.qrtz_job_details, quartz.qrtz_triggers, ...
store.ConfigureStore(options => options.TablePrefix = "quartz.qrtz_");
store.UseWeaselForPostgres();

Every apply takes a session advisory lock first, so nodes starting together, or a node starting during db-apply, take turns. The others then find nothing left to do.

store.UseWeaselForPostgres(weasel =>
{
    // unset: the active JasperFx profile's ResourceAutoCreate, else CreateOrUpdate
    weasel.AutoCreate = AutoCreate.CreateOrUpdate;
    weasel.LockId = PostgresWeaselOptions.DefaultLockId;
    weasel.LockTimeout = TimeSpan.FromMinutes(1);
});

LockTimeout bounds the wait; an apply that times out fails like any other.

Inside a Marten store

To have Marten own the tables, add them as a feature schema and leave UseWeaselForPostgres() out:

builder.Services.AddMarten(connectionString).ApplyAllDatabaseChangesOnStartup();

// the same tables, with the scheduler's table prefix
builder.Services.ConfigureMarten((services, opts) =>
    opts.Storage.Add(QuartzPostgresFeatureSchema.ForScheduler(services)));

• Marten applies them with its own schema: at startup, db-apply and resources setup. Marten's AutoCreate, migrator and lock (4004) apply; PostgresWeaselOptions does not.
• CompletelyRemoveAllAsync leaves them alone. Storage.ExtendedSchemaObjects would drop them with CASCADE.
• ApplyAllDatabaseChangesOnStartup() is required, or db-apply / resources setup before the first start. Without either, Marten creates nothing at startup and the store's schema validation fails on the missing tables.
• ForScheduler refuses a scheduler that also calls UseWeaselForPostgres(). Constructing new QuartzPostgresFeatureSchema(prefix) directly is not checked.
• One Quartz feature per Marten store: Marten keeps one feature per type.

SQL Server

The schema is the table prefix's: quartz.QRTZ_ or [quartz].QRTZ_ puts the tables in schema quartz. Without one it is dbo. Every name is the script's: PK_QRTZ_TRIGGERS, FK_QRTZ_TRIGGERS_QRTZ_JOB_DETAILS, IDX_QRTZ_T_NFT_ST.

Every apply takes a session application lock (sp_getapplock) first, so nodes starting together, or a node starting during db-apply, take turns. The lock is scoped to the database.

// tables quartz.QRTZ_JOB_DETAILS, quartz.QRTZ_TRIGGERS, ...
store.ConfigureStore(options => options.TablePrefix = "quartz.QRTZ_");
store.UseWeaselForSqlServer(weasel =>
{
    // unset: the active JasperFx profile's ResourceAutoCreate, else CreateOrUpdate
    weasel.AutoCreate = AutoCreate.CreateOrUpdate;
    weasel.LockResource = SqlServerWeaselOptions.DefaultLockResource;
    weasel.LockTimeout = TimeSpan.FromMinutes(1);
});

LockTimeout bounds the wait, even past the connection's command timeout; an apply that times out fails like any other.

MySQL

The database is the table prefix's: quartz.QRTZ_ puts the tables in database quartz. Without one it is the connection string's Database; a connection that names none is refused. Weasel's own default, public, is never used. Every name is the script's, and the foreign keys are the ones InnoDB names: QRTZ_TRIGGERS_ibfk_1.

Every apply takes a user lock (GET_LOCK) first, on a connection of its own, so nodes starting together, or a node starting during db-apply, take turns. It needs no privilege. The lock is scoped to the server, not the database: schedulers on other databases of one server take turns too, unless each has its own LockName.

store.UseWeaselForMySql(weasel =>
{
    // unset: the active JasperFx profile's ResourceAutoCreate, else CreateOrUpdate
    weasel.AutoCreate = AutoCreate.CreateOrUpdate;
    // server-wide: give each database its own name to keep their applies apart
    weasel.LockName = MySqlWeaselOptions.DefaultLockName;
    weasel.LockTimeout = TimeSpan.FromMinutes(1);
});

LockTimeout bounds the wait, even past the connection's command timeout; an apply that times out fails like any other.

Oracle

The schema is the table prefix's: quartz.QRTZ_ puts the tables in schema QUARTZ. Without one it is the session's current schema, SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA'): the login's own, or the schema a logon trigger moves the session to. Weasel's own default, WEASEL, is never used. Every name is the script's: QRTZ_TRIGGERS_PK, QRTZ_TRIGGER_TO_JOBS_FK, IDX_QRTZ_T_NFT_ST.

No lock is taken, because DBMS_LOCK needs an EXECUTE grant the store never needs. Appliers race instead, as ProvisionSchema() does: an apply that loses a statement to another session (ORA-00054, ORA-00955, ORA-01418, ORA-01430, ORA-02260, ORA-02275) reads the schema again, and stops when another process has finished it (event 10009). It gives up after 10 attempts. Any other failure fails the apply at once, as a SchedulerException naming the scheduler and the database.

Firebird

Firebird 3, 4 and 5. Firebird has no schemas, so a table prefix with a dot is refused. Every name is the script's: PK_QRTZ_TRIGGERS, FK_QRTZ_TRIGGERS_1, IDX_QRTZ_T_NFT_ST.

No lock is taken: Weasel.Firebird has none. Every statement it runs is guarded, so a statement that loses a race to another applier runs again and finds the object there. An apply that still fails with a race error (an object that already exists, a catalog unique key, a lock conflict or time-out, an update conflict) reads the schema again, and stops when another process has finished it (event 10009). Any other failure fails the apply at once, as a SchedulerException naming the scheduler and the database.

A prefix too long for the limit is refused before anything runs. Names are never truncated.

// IDX_QRTZ_REPORTING_FT_INST_JOB_REQ_RCVRY is 40 characters, past Firebird 3's 31 bytes
store.ConfigureStore(options => options.TablePrefix = "QRTZ_REPORTING_");
store.UseWeaselForFirebird(weasel =>
{
    // unset: the active JasperFx profile's ResourceAutoCreate, else CreateOrUpdate
    weasel.AutoCreate = AutoCreate.CreateOrUpdate;
    // only for a database Firebird 3 never opens
    weasel.MaxIdentifierLength = 63;
});

Weasel.Firebird was contributed to Weasel in JasperFx/weasel#666. Thanks to the JasperFx maintainers for merging it.

SQLite

• The store must use UseSqlite: Weasel speaks Microsoft.Data.Sqlite only.
• No lock is taken. The file serializes writers, every CREATE is guarded, and an ADD COLUMN that loses a race is re-read and found done. Any other failure fails the apply at once, as a SchedulerException naming the scheduler and the database.
• SQLite makes some changes by rebuilding the table. The rebuild keeps your own columns, indexes and foreign keys, with their rows, and so does rolling it back with db-patch's .drop.sql.
• A rebuild that fails rolls back and changes nothing. The usual cause is a row that the restored foreign key rejects, such as a trigger whose job is gone.

Moving off Weasel.Quartz.Postgres

Weasel.Quartz.Postgres was the first Weasel integration for Quartz.NET — thanks to Jaedyn for building it. The Quartz.Weasel packages need Quartz 4.3; an application still on Quartz 3.x keeps Weasel.Quartz.Postgres until it upgrades.

Its table and constraint names are PostgreSQL's defaults, as here, so switching renames nothing and rebuilds no table. The first apply is a 3.x-to-4.x upgrade: idx_qrtz_t_nft_st is dropped and recreated in its 4.x shape, the 4.x columns and tables are added, and any retired 3.x index names are dropped.

1. Remove the Weasel.Quartz.Postgres package.
2. Replace QuartzSchema.Create(...) with UseWeaselForPostgres() on the store.
3. With Marten, replace options.Storage.ExtendedSchemaObjects.AddRange(QuartzSchema.AllTables()) with the feature schema above.

See also

• Wolverine — Quartz beside Wolverine
• Job stores — the ADO.NET store and its schema
• Schema changes — every schema version and its migration