Skip to main content
MediPro is built on Laravel and supports SQLite, MySQL, and PostgreSQL. For local development, SQLite is the default and requires no additional server setup. The database is used primarily for Laravel’s built-in infrastructure — authentication, cache, sessions, and queued jobs — rather than for storing window and door configuration data.
Window and door configurations in MediPro are stored in the PHP session, not in the database. The database tables created by migrations support Laravel’s core features: user authentication, cache storage, and the job queue. See Session data below for the full list of session keys used by the configurator.

​
Supported databases

SQLite

Default for local development. No server required — uses a single file at database/database.sqlite.

MySQL

Recommended for production deployments on shared hosting and traditional LAMP stacks.

PostgreSQL

Suitable for production deployments where PostgreSQL is the standard or preferred database.

​
Configuration

Set the database connection in your .env file. 
DB_CONNECTION=sqlite
# No additional variables needed.
# Laravel uses database/database.sqlite by default.
For SQLite, create the database file if it does not exist: 
touch database/database.sqlite

​
Migration commands

# Run all pending migrations
php artisan migrate

# Drop all tables and re-run every migration from scratch
php artisan migrate:fresh

# Show the status of each migration (run / pending)
php artisan migrate:status
php artisan migrate:fresh destroys all data in the database. Never run this against a production database.

​
Migrations overview

MediPro ships with three migration files. All are standard Laravel scaffolding.

​
0001_01_01_000000_create_users_table

Creates three tables for authentication and session management. users
ColumnTypeNotes
idbigint, PKAuto-incrementing primary key
namevarcharUser’s display name
emailvarchar, uniqueUser’s email address
email_verified_attimestamp, nullableWhen the email address was verified
passwordvarcharBcrypt-hashed password
remember_tokenvarchar, nullableToken for “remember me” sessions
created_attimestamp—
updated_attimestamp—
password_reset_tokens
ColumnTypeNotes
emailvarchar, PKThe address the reset was requested for
tokenvarcharHashed reset token
created_attimestamp, nullableWhen the token was issued
sessions Used when SESSION_DRIVER=database. Stores all active session payloads.
ColumnTypeNotes
idvarchar, PKSession identifier
user_idbigint, nullable, indexedAssociated user (if authenticated)
ip_addressvarchar(45), nullableClient IP address
user_agenttext, nullableClient user-agent string
payloadlongtextSerialised session data (includes all MediPro configurator state)
last_activityinteger, indexedUnix timestamp of the last request

​
0001_01_01_000001_create_cache_table

Creates two tables used when CACHE_STORE=database. cache
ColumnTypeNotes
keyvarchar, PKCache key
valuemediumtextSerialised cached value
expirationintegerUnix timestamp when the entry expires
cache_locks
ColumnTypeNotes
keyvarchar, PKLock identifier
ownervarcharProcess that holds the lock
expirationintegerUnix timestamp when the lock expires

​
0001_01_01_000002_create_jobs_table

Creates three tables used when QUEUE_CONNECTION=database. jobs
ColumnTypeNotes
idbigint, PKAuto-incrementing job ID
queuevarchar, indexedQueue name
payloadlongtextSerialised job payload
attemptstinyint unsignedNumber of times the job has been attempted
reserved_atint unsigned, nullableUnix timestamp when a worker claimed this job
available_atint unsignedUnix timestamp when the job becomes available
created_atint unsignedUnix timestamp when the job was dispatched
job_batches Supports Laravel’s job batching feature.
ColumnTypeNotes
idvarchar, PKBatch identifier
namevarcharHuman-readable batch name
total_jobsintegerTotal jobs in the batch
pending_jobsintegerJobs not yet completed
failed_jobsintegerJobs that have failed
failed_job_idslongtextJSON array of failed job IDs
optionsmediumtext, nullableSerialised batch options
cancelled_atinteger, nullableUnix timestamp if the batch was cancelled
created_atintegerUnix timestamp of batch creation
finished_atinteger, nullableUnix timestamp when all jobs completed
failed_jobs
ColumnTypeNotes
idbigint, PKAuto-incrementing ID
uuidvarchar, uniqueUnique identifier for the failed job
connectiontextQueue connection name
queuetextQueue name
payloadlongtextSerialised job payload
exceptionlongtextFull exception trace
failed_attimestampWhen the failure occurred (defaults to now)

​
Session data

Because MediPro uses session-based state for all configurator data, no additional migrations are needed for window or door records. All configuration state is serialised into the payload column of the sessions table (or into the session file, depending on SESSION_DRIVER). The following session keys are used by the application:
Session keyTypeDescription
sistemaSeleccionadostringThe selected window system type (e.g., sliding, casement)
ventanasarrayFull array of all window configuration objects for the current batch
datos_lotearrayBatch-level metadata used when generating the print view
PuertaSeleccionadostringThe selected door type
puertasarrayDoor configuration data for the current batch
This design means that:
  • No application-specific schema changes are needed when updating MediPro.
  • Configurations are user-scoped and ephemeral by default (they last for the session lifetime defined by SESSION_LIFETIME).
  • Clearing or expiring a session resets the configurator state entirely.

Build docs developers (and LLMs) love

Get started for freeTalk to us