Enum SchemaProvisioning

Namespace

Quartz

Assembly

Quartz.dll

What a persistent job store does about its schema when it starts.

public enum SchemaProvisioning

Fields

CreateIfMissing = 2

Create whatever the schema is missing, then validate it.

Only ever creates: no object is altered and none is dropped, so this is safe to leave on against a schema that already exists and cannot turn a mis-typed table prefix into data loss. It is equally not an upgrade — a schema that has every table but is missing a column added by a later release is left exactly as it is.

Which is why it refuses a schema 4.x did not create rather than building around it: if a table it needs is already there and short of a column it needs, that table was made by something else — a 3.x deployment, in every case that matters — and creating the rest would make a scheduler that starts, reports itself provisioned and then fires nothing. Nothing is created, and the failure names the migration to run.

Not the default, because creating tables needs DDL permission and a production database is usually right not to grant the scheduler any. It is what a test fixture, a container that starts with an empty volume, or a desktop application with a SQLite file wants.

Safe on several nodes starting at once: whichever loses the race sees its create fail, finds the schema another node created, and carries on — and a schema a node left half-made is one the next node finishes, since every table in it is 4.x's own.

None = 0

Assume the schema is there. The store issues its first statement against whatever it finds.

The failure this saves a few milliseconds at the cost of is a bad one: the first operation to touch a missing table reports a provider error naming one table, at whatever moment the scheduler happened to need it, rather than a startup failure naming the schema.

Validate = 1

Check at startup that every table the store reads and writes can be queried, and refuse to start when one cannot. The default.

The columns 4.x added to the tables 3.x already had are checked too, so a database that never took the 4.0 migration is refused rather than started: it has every table but two, and a table-level check let it run and then fail every acquisition for ever. What is not checked is the shape of a column — a type or a width a hand-built table got wrong is still found by the statement that binds it. database/migrations/4.0/ is what an upgrade runs.

Remarks

This replaces the PerformSchemaValidation flag, which could only say whether the store checked. The check and the creation are one decision — a store that may create its schema obviously validates it too — so they are one setting with three positions rather than two flags that can contradict each other.

There is deliberately no "create or migrate" position. Nothing in the schema records which version it is, and SQLite's ADD COLUMN has no conditional form, so a store cannot tell a schema that is one release old from one that is five and cannot safely try. Upgrading a schema stays a decision someone makes with the scripts under database/migrations/.