> For the complete documentation index, see [llms.txt](https://vladimirkostikov.gitbook.io/laraboom/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladimirkostikov.gitbook.io/laraboom/data-model/06-schema.md).

# 6. Schema and sync

LaraBoom does not ask you to write a migration for every Resource field. The source of truth is `fields()` together with `#[Migrate]`. The `php boom sync` command brings MySQL in line with that description.

Package Laravel migrations (infrastructure) are still there. After they run, sync can kick in automatically.

## Schema commands

| Command                                              | What it does                                                     |
| ---------------------------------------------------- | ---------------------------------------------------------------- |
| `php boom schema`                                    | the status of all Migrate resources. Columns, drift, rows, seeds |
| `php boom schema {resource}`                         | expected vs actual columns                                       |
| `php boom schema --check [--json]`                   | CI. Non zero exit on drift or missing items                      |
| `php boom sync [resource] [--dry]`                   | create or change tables and columns                              |
| `php boom sync:drop {resource} --force`              | drop the resource table                                          |
| `php boom sync:prune [resource] --force`             | drop database columns that the Resource does not have            |
| `php boom rebuild --force [--seed\|--fresh] [--dry]` | drop all Migrate tables and create them again                    |
| `php boom doctor`                                    | key, database, drift, queue, seeds                               |
| `php boom migrate ...`                               | classic package migrations (plus auto sync)                      |
| `php boom install [--fresh]`                         | key + migrate + sync + seed                                      |

`{resource}` is a name like `demos`, not the `Demo` class.

## What the synchronizer can do

During `sync` it can:

1. create the table if it is missing
2. add missing columns from the fields
3. rename columns according to `->was()`
4. fix type / null / default on a mismatch
5. ensure timestamps, softDeletes and account columns
6. put unique and index in place based on the field flags
7. add or remove the FK for `Link`

`--dry` shows the plan without writing.

## The author work cycle

1. You added a field in `fields()`.
2. You ran `php boom sync` (or `sync demos`).
3. You checked `php boom schema demos` and the drift is clean.
4. If needed, `php boom seed demos`.

A rename:

```php
Text('full_name', needed: true)->was('name')
```

```bash
php boom sync demos
```

Removing a field from code does not drop the column from the database by itself. That is deliberate. When you are ready to clean up:

```bash
php boom sync:prune demos --force
```

## rebuild

A nuclear reset of the data in Migrate tables:

```bash
php boom rebuild --force --seed
```

Use it in development. In production only if you understand the data loss.

## schema --check in CI

```bash
php boom schema --check --json
```

It fails if a table is missing or the columns have diverged from the Resource. Handy after a merge where somebody forgot to sync on a stand.

## doctor

```bash
php boom doctor
```

A health summary of the host. Whether there is an `APP_KEY`, whether the database is alive, whether there is drift, the queue, seed coverage. The first tool after "nothing works for me".

## explain

Close in spirit:

```bash
php boom explain demos
```

It prints the fields, allow, filters, relations and custom routes of the resource. Handy to read the resource through the eyes of the runtime instead of just the file.

## Soft deletes and sync

`#[Migrate(softDeletes: true)]` adds the `deleted_at` column. `query()` adds `whereNull(deleted_at)`. The model `delete()` sets the timestamp.

A hard delete is a separate task (prune or raw). CRUD destroy is soft by default when softDeletes is on.

## Account and sync

`#[Account]` extends the schema with the Laravel user fields (`email_verified_at`, `remember_token`) and binds the auth model.

## How to think about it

Sync is about structure, not about data (seeding is separate).

Do not mix manual ALTERs in production with a forgotten `fields()`. The source of truth must stay in the Resource.

`sync:prune` and `rebuild` require `--force` for a reason.

## An example development session

Adding an `sku` field to a product:

```php
Text('sku', needed: true, max: 64)->unique()->filter(),
```

```bash
php boom sync products --dry    # the plan
php boom sync products           # apply
php boom schema products         # compare
php boom explain products        # the field is visible to the runtime
```

Renaming `sku` to `article`:

```php
Text('article', needed: true, max: 64)->unique()->filter()->was('sku'),
```

```bash
php boom sync products
```

Once things are stable you can drop `->was('sku')` only when every environment has already been renamed. Otherwise a fresh `rebuild` on an empty database creates `article` right away, while an old stand without `was` gets a new column next to the old one.

## Package migrations and Resource sync

|          | Laravel migrate (package)                             | boom sync                         |
| -------- | ----------------------------------------------------- | --------------------------------- |
| What     | infrastructure (jobs, cache, notifications and so on) | Resource tables with `#[Migrate]` |
| Author   | mostly the package                                    | you in `fields()`                 |
| Rollback | migrate rollback                                      | `sync:drop` / `rebuild` / prune   |

The usual order on a clean host. `php boom install` already does migrate, sync and seed.

## The install command

```bash
php boom install
php boom install --fresh
```

End to end initialization. Key, migrations, sync, seed, related steps like the storage link. This is exactly what `composer setup` calls in apps.

## JSON reports

```bash
php boom schema --json
php boom schema --check --json
```

Handy to parse in scripts. A non zero code with `--check` means do not deploy, sync first.

## Common drift messages

* missing table. There is a Resource with Migrate but no table. Run `sync`.
* missing column. You added a field and forgot to sync.
* type mismatch. You changed Text to Number or Money without sync, or with an incompatible ALTER.
* extra column. A column in the database with no field in the Resource. Bring the field back or run `sync:prune --force`.

Next up is [JSON API](/laraboom/http/07-json-api.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://vladimirkostikov.gitbook.io/laraboom/data-model/06-schema.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.