Configuration.

php artisan vendor:publish --tag="hold-config"

Publishing is optional. The defaults work for an application whose table can be called holds and whose models use integer primary keys.

return [
    'table' => 'holds',

    'holdable_key_type' => env('HOLD_HOLDABLE_KEY_TYPE', 'int'),

    'holder_key_type' => env('HOLD_HOLDER_KEY_TYPE', 'int'),
];

table

The name of the one table the package uses. The Hold model and the migration read the same value, so nothing else changes when you rename it.

'table' => 'resource_holds',

Set it before migrating. Renaming a table that already carries history takes a migration of your own.

The migration derives its index names from this value, so a rename also renames the indexes on a fresh install. See database schema.

holdable_key_type and holder_key_type

The primary key type of the models on each side of a hold. Four values are accepted:

holdable_key_type shapes holdable_id. holder_key_type shapes both holder_id and released_by_id, because a releaser is an actor of the same kind as a holder.

HOLD_HOLDABLE_KEY_TYPE=uuid
HOLD_HOLDER_KEY_TYPE=ulid

The two are independent. A UUID-keyed resource held by an integer-keyed user is a supported combination.

An unrecognised value throws at migration time, rather than producing a column that silently truncates keys:

Unsupported hold key type [bigint]. Use int, uuid, ulid, or string.

Mixed key types on one side

Both traits are polymorphic, so several models can be holdable at once. They have to agree on a key type, because one column serves all of them.

If your holdables genuinely mix integer and UUID keys, set that side to string. It stores either, at the cost of a wider index and no numeric ordering.

Changing values after migrating

Every key here shapes the table. Changing one afterwards requires a migration of your own:

There is no automatic path for either. The package reads config at runtime for the table name and at migration time for the key types, so a mismatch between config and schema surfaces as a database error rather than as a silent fallback.

What is not configurable

The package has three keys and no more. In particular:

• No retention window. hold:prune takes --days per invocation. See pruning history.
• No schedule registration. Both commands are optional, and you schedule them yourself.
• No default capacity. Capacity is declared on the model through holdCapacity(), never in config, because every concurrent acquirer has to read the same limit. See capacity and slots.
• No model override. The Hold model is final. Extend behaviour through events rather than by swapping the class.

What to read next

• Database schema for what these keys produce.
• Installation and setup for the order to publish and migrate in.
• Console commands for the options that are per-run rather than configured.