Database schema & key types

Five tables back the package. Table names come from table_names; column names are fixed:

Holder links are polymorphic (model_type + model_id), so any Eloquent model can hold roles and permissions — not just users. Custom morph-map aliases are stored in the pivots as they are everywhere else in Laravel.

Holder key type

key_type describes the models that hold roles and permissions — never this package’s own tables, which always keep an auto-incrementing key. It types the model_id column on the two polymorphic pivots:

Set it before you publish and run the migrations — the schema freezes at release:

PERMISSIONS_KEY_TYPE=uuid

use Illuminate\Database\Eloquent\Concerns\HasUuids;
use Illuminate\Foundation\Auth\User as Authenticatable;
use RoundlyConsulting\Permissions\Concerns\HasRoles;

class User extends Authenticatable
{
    use HasRoles;
    use HasUuids; // pairs with PERMISSIONS_KEY_TYPE=uuid
}

Unset or blank reads as bigint; an unrecognized value throws the toolkit’s InvalidConfigurationException rather than silently building bigint keys.

Hard deletes by design

Roles and permissions do not use soft deletes: the unique name index would clash with soft-deleted rows, and every pivot cascades on delete — removing a role or permission removes its grants with it.