# Migracje bazy danych (SurrealDB)

Migracje w SurrealQL, wersjonowane w git. Backend (plik/RocksDB) jest źródłem prawdy; frontend (WASM) stosuje ten sam podzbiór definicji przy starcie.

## Pliki

| Plik | Zawartość |
|---|---|
| `0001_schema.surql` | tabele, pola, indeksy (w tym HNSW + pełnotekstowy), `ACCESS`, `PERMISSIONS`, `ASSERT` |
| `0002_taxonomy_seed.surql` | 8 obszarów (`social_challenge`), tagi, próbka lokalizacji |
| `0003_demo_seed.surql` | dane syntetyczne (dodawane w kroku 09) |

## Zasady

- Numeracja `NNNN_nazwa.surql`, stosowana w kolejności rosnącej.
- Migracje **idempotentne** (`DEFINE ... OVERWRITE`, `INSERT IGNORE`), addytywne.
- Zmiany schematu wyłącznie przez nowy plik migracji — bez ręcznych zmian na środowisku.
- Brak danych osobowych/wrażliwych w seedach (krok 09).

## Aplikowanie

SurrealDB CLI 3.x. `surreal sql` nie ma już flagi `--file` — przekaż plik przez stdin z `--multi` (średniki rozdzielają instrukcje):

```pwsh
Get-Content -Raw backend/migrations/0001_schema.surql | `
  surreal sql -e http://127.0.0.1:18010 -u root -p root --ns hubmi --db hubmi --hide-welcome --multi
Get-Content -Raw backend/migrations/0002_taxonomy_seed.surql | `
  surreal sql -e http://127.0.0.1:18010 -u root -p root --ns hubmi --db hubmi --hide-welcome --multi
```

Alternatywnie `surreal import` — wymaga `OPTION IMPORT;` jako pierwszej instrukcji pliku (wyłącza przetwarzanie pól).

Embedded RocksDB: uruchom `pwsh ./scripts/surrealdb-start.ps1` (tryb zdalny) albo zastosuj migracje przez backend przy starcie (krok 10).

## Weryfikacja

Zwalidowano na **SurrealDB 3.2.4** (instancja in-memory): schemat i seed aplikują się bez błędów, ponowne uruchomienie jest idempotentne (22 tabele, 8 obszarów, 18 tagów, 4 lokalizacje), a CRUD na encjach (`create`/`update`/`select`/`delete`) działa.

## Frontend (WASM)

Frontend stosuje podzbiór `0001_schema.surql` do `indxdb://tarninahub` (bez serwerowych `PERMISSIONS` i `ACCESS`). Reguły synchronizacji: patrz `10_ZalozeniaProjektowe/todo08/BAZA_DANYCH.md` §6.