# berita_kelas Local DB Rebuild — Design

Date: 2026-09-15
Status: Executed

## Context

Local `berita_kelas` (Laragon MySQL 8.4.3, root/empty, port 3306) was out of sync
with the app code in this repo. The production dump
`D:\Setup\nuogwcpc_beritakelas (1).sql` was used as the source of truth.

## Problems found

1. Dump corruption: `jadwal_gabungan` view's first UNION branch exported with
   only 3 of 12 columns ("The used SELECT statements have a different number of
   columns" on import).
2. Dump views carry `DEFINER=nuogwcpc@localhost` (user does not exist locally).
3. `view_barang` view unused by any app code.
4. `barang_mhs` view outdated vs app: `DataBarangDataTable` and `lapor-btn`
   need `kelas_id, nama, merk, kondisi, jumlah, barang_grup_id` but the view
   only exposed `barang_grup_id, nama` (broken Lapor Kerusakan page, in
   production too).
5. `jadwal_gabungan` view carried `kolom` / `mata_kuliah_id` which no view
   consumer uses (both are used on the `jadwal_ruangan` table only).
6. Junk: production `sessions` / `cache` rows; one orphan `jadwal_ruangan` row
   (id 213, empty kelas/mata_kuliah, kelas_id pointing at nothing).

## Executed design

1. Backup old local DB → `D:\Setup\berita_kelas_local_backup_2026-09-15.sql`.
2. Import via temp copy of dump with DEFINER stripped and the broken
   `jadwal_gabungan` first branch restored (original dump untouched).
3. Truncate `sessions`, `cache`, `cache_locks`; delete orphan jadwal row 213.
4. Recreate `barang_mhs` with the 6 app-used columns (COUNT(*) AS jumlah).
5. Recreate `jadwal_gabungan` without `kolom` / `mata_kuliah_id`
   (10 columns remain).
6. Drop `view_barang`.
7. Sync repo: `database/berita-kelas-schema.sql` view sections updated,
   `2026_08_18_200000_...jadwal_gabungan_view.php` up() trimmed,
   new `2026_09_15_000000_fix_barang_mhs_view.php` pins the fixed view.

## Known pre-existing issues

- ~~`migrations` table mismatch~~ **Resolved (2026-09-15)**: deleted abandoned
  `2024_08_15_074020_create_barang_assignments_relation_table.php` (its
  `barang.kelas_id`/`personal_id` columns + `barang_assignments` table never
  existed — the app uses the polymorphic `assigned_type`/`assigned_id`
  design), removed 7 orphan migration records, and registered the 11 real
  migration files as batch 7. `php artisan migrate` now reports "Nothing to
  migrate".
- `jadwal_ruangan` FKs **added** (kelas CASCADE, dosen/mata_kuliah SET NULL) —
  all 8 FKs now match the documented schema.
- **Warning**: `php artisan migrate:rollback` would run batch 7's `down()`
  methods — `import_jadwal_from_sheet8` truncates `jadwal_ruangan`. Avoid
  rollback/reset/fresh against this DB.

## Verification results

- 21 tables + 2 views present; 5 FKs (matches production dump).
- `ViewBarang::where('kelas_id', ...)` → 17 rows; `JadwalGabungan` queries and
  `dataPersonil` relation OK.
- `php artisan serve` smoke test → HTTP 200.