feat: move to POSTGRES, keep H2 for testing

README.md

@@ -1,6 +1,6 @@
 # java-backend
 ## How to run springboot application
-
+### IntelliJ IDEA
 1. Install Lombok Plugin
 
 - Install Lombok plugin - should be suggested in the bottom right corner of IntelliJ
@@ -16,6 +16,7 @@
 - If the green arrow in top right corner is grey find main class: src/main/java/com/backend/BackendApplication.java and click on the green arrow next to a main class
 - From now on, you can use the green arrow in top right corner
 
+### Terminal / browser / dev
 4. Test the Application
 
 - Go to http://localhost:8080/hello/
@@ -24,21 +25,24 @@
 5. Unit tests
 - test are automaticly run by a ci workflow, do not merge until you pass them
 
-6. Docker
-- On merge to main docker image is build and pushed to dockerhub with latest tag
-- See https://hub.docker.com/repository/docker/haniazipser2004/awesome-amazing-project
-- docker pull haniazipser2004/awesome-amazing-project:latest
-- docker run -p 8080:8080 haniazipser2004/awesome-amazing-project:latest (or different port mapping if 8080 is in use)
+6. Migrations
+- We use flyway for database migrations, which means that if you want to update the database schema, 
+you need to create a new migration file in src/main/resources/db/migration.
+- If you manage to "break" the database, you can reset it by running `docker compose down -v` (this will remove the postgres data volume associated with the compose file
 
 7. Docker compose
-  If you want to run whole backend (java + python + keycloak):
-- clone this repo
-- run compose.yaml
+
+**If you want to run whole backend locally, fast (java + keycloak + rabbitmq + postgres db)**:
+- run compose.yaml (see pt. 2 of `6. Migrations`)
+- run spring boot application (see `3. Run Spring Boot Application`)
 - Java backend -> http://localhost:8080
 - Keycloak -> http://localhost:8081
-- Python microservice -> http://localhost:8000
+- POSTGRES DB shell -> `docker exec -it <container_id> psql -U postgres` (use `docker ps` to find container id)
+
+If you want to run the backend with the containerized version of java as a sanity check:
+- run full_compose.yaml with `docker compose -f full_compose.yaml up`
 
-7. Documentation
+9. Documentation
 - Documentation is generated under http://localhost:8080/swagger-ui/index.html
 - To add custom descrtptions see example controller
 

ai/01-postgres_migration/01-DEVELOPER_WORKFLOW.md

@@ -0,0 +1,89 @@
+# Developer Workflow
+
+## Manual Testing (Frontend + Backend)
+
+**Start infrastructure once:**
+```bash
+docker compose up postgres keycloak rabbitmq elasticSearch -d
+```
+Then run the backend from your IDE or terminal (`dev` profile). The app connects to all services via `localhost`. Flyway runs automatically on startup and applies any pending migrations.
+
+**What you need to worry about:**
+- Docker must be running
+- If you changed the schema, write a new migration file first (see [Schema Changes](#schema-changes)) — the app won't start if `ddl-auto=validate` detects a mismatch
+
+**What is taken care of:**
+- Schema is created and kept up to date by Flyway at every app startup
+- Seed data (restaurants, dishes, etc.) is loaded once by Flyway and persists across restarts
+- No Docker image rebuild needed — edit code, restart app, done
+
+---
+
+## Unit & Integration Tests
+
+```bash
+mvn test
+```
+
+Tests currently use an **H2 in-memory database** with Flyway disabled. Hibernate manages the schema directly via `ddl-auto=create-drop`, creating a fresh schema at the start of each test run and dropping it at the end. This is configured in `src/test/resources/application.properties`.
+
+**What you need to worry about:**
+- Nothing — no external database or Docker required to run tests
+
+**What is taken care of:**
+- Tests are fully isolated — each run starts from a clean schema
+- CI runs these same tests identically without any database infrastructure
+
+> **Planned:** Once Flyway is confirmed working end-to-end, the test setup will be migrated to **Testcontainers**, which spins up a real PostgreSQL Docker container automatically for the test run and tears it down when done. Flyway migrations will run inside that container, so tests will always run against the real schema. When that is done, Docker must be running to execute tests, and the `src/test/resources/application.properties` override will be removed.
+
+---
+
+## Schema Changes
+
+Whenever you modify an entity (add a column, rename a field, add a table, etc.):
+
+1. **Create a new migration file** in `src/main/resources/db/migration/`:
+   ```
+   V{next_number}__{short_description}.sql
+   ```
+   Example: `V3__add_user_preferences_table.sql`
+
+2. **Never edit an existing migration file.** Flyway checksums every applied migration — modifying one will cause a checksum mismatch and the app (and tests) will refuse to start.
+
+3. Restart the app locally — Flyway applies the new migration automatically.
+
+Everything downstream (tests, staging, production) picks up the migration without additional steps.
+
+---
+
+## Deploying to Staging
+
+Triggered automatically on merge to the `staging` branch (or equivalent) via GitHub Actions:
+
+1. Build & test (`mvn verify` — includes Testcontainers tests)
+2. Build and push Docker image
+3. **Run `mvn flyway:migrate` against the staging database** using secrets stored in GitHub — migration runs and is verified *before* the app is deployed
+4. `helm upgrade` rolls out the new image to AKS
+
+**What you need to worry about:**
+- Your migration SQL must be correct before merging — if `flyway:migrate` fails, the pipeline stops and the old version keeps running untouched
+
+**What is taken care of:**
+- Database is migrated before any pod restarts
+- No manual database access required
+- Rollback: if migration fails, deployment does not proceed
+
+---
+
+## Deploying to Production
+
+Same pipeline as staging, triggered on merge to `main` (or a release tag), using production secrets.
+
+**What you need to worry about:**
+- Migration was already validated on staging — verify staging is healthy before promoting to production
+- Migrations are **irreversible by default** — dropping a column or table cannot be undone automatically; plan destructive changes carefully
+
+**What is taken care of:**
+- CI runs the migration against the production database before deploying
+- No developer needs direct production database access for routine deployments
+- Zero-downtime is achieved by ensuring migrations are backwards-compatible (old pods can still run while new pods start)

ai/01-postgres_migration/02-POSTGRES_MIGRATION.md

@@ -0,0 +1,214 @@
+# Context
+
+The project currently uses H2 in-memory database configured identically across all three Spring profiles (dev, compose, k8s). The task "move to a proper database" means replacing H2 with PostgreSQL everywhere — including adding a Postgres container to docker-compose for local development, and provisioning Postgres for AKS. The schema is entirely auto-generated by Hibernate (`ddl-auto=create`), there are no migrations, and seed data is loaded via `data.sql` on every startup.
+
+---
+
+## How I Interpret the Task
+
+**Full scope:**
+1. Add the PostgreSQL JDBC driver to `pom.xml` (replace H2)
+2. Add a Flyway migration system (critical — see below)
+3. Update all three profile property files to point at PostgreSQL
+4. Add a `postgres` service to `docker/compose.yaml`
+5. Wire PostgreSQL credentials into the K8s Helm chart via a Secret
+6. Keep H2 scoped to tests only, so unit tests run without a real DB
+
+---
+
+## Non-Obvious Things You Need to Know
+
+### 1. You must add Flyway (or Liquibase) — this is the biggest non-obvious item
+Right now Hibernate creates the schema fresh every restart (`ddl-auto=create`). That's fine for H2 because the data is gone anyway. With a real PostgreSQL database, the data persists — so you can never use `create` again in compose/k8s (it drops and recreates every table, wiping all data). You need a migration tool like Flyway that tracks schema changes in versioned SQL files. Each change to the schema becomes a new migration file (e.g., `V1__init.sql`, `V2__add_column.sql`). Flyway applies only the ones that haven't been applied yet.
+
+### 2. `data.sql` behavior changes completely
+Currently, `data.sql` re-seeds the database every startup. With PostgreSQL and persistent data, that will fail on duplicate key errors after the first run. The seed data should either:
+- Move into a Flyway migration file (e.g., `V2__seed_data.sql`) that only runs once
+- Or be guarded with `INSERT ... ON CONFLICT DO NOTHING`
+
+You also need to change `spring.sql.init.mode=always` to `never` in compose/k8s profiles once Flyway is managing the schema.
+
+### 3. `ddl-auto` must differ per environment
+- **dev (local, no Docker):** Can keep `create` against a local H2 if you want, or `validate` against a local Postgres
+- **compose:** Should be `validate` (let Flyway handle schema) or `none`
+- **k8s:** Must be `validate` or `none` — never `create` or `update` in production
+
+### 4. The compose service needs a `healthcheck` and `depends_on` condition
+Docker Compose `depends_on` by default only waits for the container to *start*, not for Postgres to be *ready to accept connections*. The java-backend will crash-loop on startup if it connects before Postgres finishes initializing. You need:
+```yaml
+postgres:
+  healthcheck:
+    test: ["CMD-SHELL", "pg_isready -U postgres"]
+    interval: 5s
+    timeout: 5s
+    retries: 5
+
+java-backend:
+  depends_on:
+    postgres:
+      condition: service_healthy
+```
+
+### 5. PostgreSQL credentials should be a Kubernetes Secret — not hardcoded
+The Helm chart already does this correctly for RabbitMQ (uses `secretKeyRef`). PostgreSQL connection details (URL, username, password) should follow the same pattern. Do not put a real password in `values.yaml` — that file is checked into git.
+
+### 6. For AKS production: consider Azure Database for PostgreSQL (managed)
+Running Postgres as a pod in AKS means you are responsible for backups, high availability, upgrades, and persistent volume claims. Azure offers a managed PostgreSQL service (Azure Database for PostgreSQL - Flexible Server) that handles all of this. For a student/small project, the in-cluster container is fine to start, but the managed service is the production-grade path. This also affects how you configure the `SPRING_DATASOURCE_URL` in the Helm chart — it would point at the Azure-managed hostname rather than a service name.
+
+### 7. UUID columns: no code changes needed, but know what Hibernate is doing
+Your entities use `UUID` IDs. PostgreSQL has a native `uuid` type; H2 stored them as `VARCHAR`. Hibernate with PostgreSQL dialect maps Java `UUID` to the native type automatically. This is handled for you — just be aware the column type will change if you're looking at the schema.
+
+### 8. Keep H2 scoped to tests
+The test suite should continue running without a real database. Add a `src/test/resources/application.properties` that overrides the datasource back to H2, so `@DataJpaTest` and integration tests keep working in CI without needing a running Postgres container.
+
+---
+
+## Implementation Steps
+
+### Step 1 — `pom.xml`
+- Add `org.postgresql:postgresql` runtime dependency
+- Add `org.flywaydb:flyway-core` dependency
+- Keep `com.h2database:h2` but change scope to `test`
+
+### Step 2 — Flyway migration files
+Create `src/main/resources/db/migration/`:
+- `V1__init_schema.sql` — DDL for all tables (generate from current Hibernate schema or write by hand from entity inspection)
+- `V2__seed_data.sql` — move the contents of `data.sql` here (seed restaurants, opening hours, dishes, etc.), guarded with `ON CONFLICT DO NOTHING`
+
+### Step 3 — Update property files
+**`application-dev.properties`** (local dev without Docker):
+```properties
+spring.datasource.url=jdbc:postgresql://localhost:5432/jucaneat
+spring.datasource.driver-class-name=org.postgresql.Driver
+spring.datasource.username=postgres
+spring.datasource.password=postgres
+spring.jpa.hibernate.ddl-auto=validate
+spring.sql.init.mode=never
+# remove h2 console lines
+```
+
+**`application-compose.properties`** (Docker Compose):
+```properties
+spring.datasource.url=jdbc:postgresql://postgres:5432/jucaneat
+spring.datasource.driver-class-name=org.postgresql.Driver
+spring.datasource.username=postgres
+spring.datasource.password=postgres
+spring.jpa.hibernate.ddl-auto=validate
+spring.sql.init.mode=never
+```
+
+**`application-k8s.properties`** (AKS):
+```properties
+# Use env vars injected by Helm — override via environment block, not hardcoded here
+spring.jpa.hibernate.ddl-auto=validate
+spring.sql.init.mode=never
+```
+The actual URL/credentials come from the K8s Secret via env vars.
+
+### Step 4 — `docker/compose.yaml`
+Add the `postgres` service and wire `java-backend` to it:
+```yaml
+postgres:
+  image: postgres:17
+  environment:
+    POSTGRES_DB: jucaneat
+    POSTGRES_USER: postgres
+    POSTGRES_PASSWORD: postgres
+  ports:
+    - "5432:5432"
+  healthcheck:
+    test: ["CMD-SHELL", "pg_isready -U postgres"]
+    interval: 5s
+    timeout: 5s
+    retries: 5
+  volumes:
+    - postgres-data:/var/lib/postgresql/data
+
+# Add to java-backend depends_on:
+depends_on:
+  postgres:
+    condition: service_healthy
+  keycloak: ...  # existing
+  ...
+
+volumes:
+  postgres-data:  # alongside existing elasticsearch-data
+```
+
+Also add `SPRING_DATASOURCE_*` env vars to the `java-backend` service block to override the compose profile properties (or rely on the profile file — either works, but env vars in compose are more visible).
+
+### Step 5 — K8s Helm chart (`k8s/helm/java-backend/`)
+Create a `postgres-secret.yaml` template (or apply it separately):
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: postgres-credentials
+type: Opaque
+stringData:
+  url: jdbc:postgresql://postgres:5432/jucaneat
+  username: postgres
+  password: <real-password>
+```
+
+Add to `values.yaml` env block:
+```yaml
+- name: SPRING_DATASOURCE_URL
+  valueFrom:
+    secretKeyRef:
+      name: postgres-credentials
+      key: url
+- name: SPRING_DATASOURCE_USERNAME
+  valueFrom:
+    secretKeyRef:
+      name: postgres-credentials
+      key: username
+- name: SPRING_DATASOURCE_PASSWORD
+  valueFrom:
+    secretKeyRef:
+      name: postgres-credentials
+      key: password
+- name: SPRING_PROFILES_ACTIVE
+  value: k8s
+```
+
+If using Azure Database for PostgreSQL, the URL hostname changes to the Azure-managed endpoint.
+
+### Step 6 — Test configuration
+Create `src/test/resources/application.properties`:
+```properties
+spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1
+spring.datasource.driver-class-name=org.h2.Driver
+spring.datasource.username=sa
+spring.datasource.password=
+spring.jpa.hibernate.ddl-auto=create-drop
+spring.sql.init.mode=never
+```
+This keeps tests isolated from the real DB.
+
+---
+
+## Critical Files to Modify
+
+| File | Change |
+|------|--------|
+| `pom.xml` | Add postgres driver, Flyway; move H2 to test scope |
+| `src/main/resources/application-dev.properties` | Switch to PostgreSQL datasource |
+| `src/main/resources/application-compose.properties` | Switch to PostgreSQL datasource |
+| `src/main/resources/application-k8s.properties` | Use env-var-driven datasource |
+| `docker/compose.yaml` | Add postgres service + volume + healthcheck |
+| `k8s/helm/java-backend/values.yaml` | Add DB env vars from secret |
+| `k8s/helm/java-backend/templates/` | Add postgres Secret template (or apply manually) |
+| `src/main/resources/db/migration/V1__init_schema.sql` | New: schema DDL |
+| `src/main/resources/db/migration/V2__seed_data.sql` | New: moved from data.sql |
+| `src/test/resources/application.properties` | New: keep H2 for tests |
+
+---
+
+## Verification
+
+1. **Local compose:** `docker compose up` → all services start → `curl localhost:8080/health` returns 200 → data endpoints return restaurants/dishes
+2. **Flyway ran:** Connect to the Postgres container (`psql -h localhost -U postgres jucaneat`) → `SELECT * FROM flyway_schema_history;` shows V1 and V2 applied
+3. **Data persistence:** Stop and restart compose → data still present (was previously lost on every restart with H2)
+4. **Tests still pass:** `mvn test` — unit/integration tests pass using H2 in-memory without needing Postgres running
+5. **K8s:** `helm upgrade --install java-backend ./k8s/helm/java-backend` → pod starts, Flyway applies migrations on first boot, app serves traffic