Migrate database schema management from SQL to Liquibase

[mucsi96]

Summary

This PR migrates the database schema management from Spring's SQL initialization to Liquibase, a dedicated database migration tool. This provides better version control, rollback capabilities, and more robust schema management.

Key Changes

• Added Liquibase dependency to pom.xml for database migration management
• Created Liquibase changelog (db/changelog/db.changelog-master.yaml) with two changesets:
  • Initial table creation for the greetings table with proper constraints
  • Seed data insertion for the initial greeting record
• Removed legacy SQL schema file (schema.sql) that was previously used for initialization
• Updated Spring configuration in application.yml:
  • Disabled Hibernate's automatic DDL generation (ddl-auto: none)
  • Removed Spring's SQL initialization configuration
  • Added Liquibase changelog configuration pointing to the new migration file

Implementation Details

• Liquibase changesets include preconditions to ensure idempotent execution (won't fail if table already exists or data is already seeded)
• The migration maintains the same database schema and initial data as the previous SQL-based approach
• Hibernate is now configured to not manage schema creation, delegating this responsibility entirely to Liquibase

https://claude.ai/code/session_01Xwj7JnFnQxBjr5YvwbB46R

[claude]

PR Review: Migrate database schema management from SQL to Liquibase

Good migration overall. Liquibase is the right tool for managing schema evolution in a production app. A few observations:

bigint + autoIncrement vs BIGSERIAL
The original schema.sql used PostgreSQL BIGSERIAL. Liquibase autoIncrement: true on a bigint column generates the equivalent sequence for PostgreSQL, so this is functionally correct.

Precondition approach
Using onFail: MARK_RAN on both changesets handles the case where Liquibase is introduced to an existing database. Reasonable migration strategy. The seed data precondition has a subtle edge: if the table already exists and has data on first Liquibase run, changeset 2 is MARK_RAN and will never insert. If the DB is fresh, the row is inserted. Once recorded in databasechangelog, Liquibase never revisits it. Fine for the intended use case.

Suggestion: Liquibase contexts for seed data
The seed data insertion is business data, not pure schema. Consider tagging changeset 2 with context: local,test so it does not run in production. If the initial greeting is intentional for all environments, ignore this suggestion.

Check profile-specific configs
The main application.yml now correctly sets ddl-auto: none. If any profile-specific YMLs (application-local.yml, application-test.yml) previously overrode ddl-auto or sql.init settings, those would need updating too.

Minor
The Liquibase dependency correctly omits version to rely on Spring Boot managed BOM.

---

Overall: clean migration that correctly delegates schema management to Liquibase, preserves the existing schema and seed data, and uses preconditions for safe bootstrapping against a pre-existing database.

[claude]

Skeleton App - Development Guidelines

General Code Style

• Avoid fallbacks, prefer failing fast
• Prefer functional programming patterns
• Prefer immutable data structures

Java Style

• Use Lombok annotations (@DaTa, @builder, @requiredargsconstructor)
• Constructor injection (via @requiredargsconstructor)
• Use Stream API for collections
• Use records for DTOs/responses

TypeScript Style

• Use const by default
• Prefer spread operator for object/array operations
• Use functional array methods (map, filter, reduce)
• Use string literals over enums

Testing Style

• Write tests from user perspective
• Use role-based selectors (getByRole)
• Use semantic selectors (getByText, getByLabel)
• E2E tests with Playwright

Angular Style

• Use Angular Material components
• Use signals and resources (not rxjs where possible)
• Use string literals over enums
• Standalone components

Design

• Material UI dark theme
• Skeleton loaders for loading states

Project Overview

Reference application demonstrating patterns for:

• CI/CD pipeline (GitHub Actions)
• Deployment (Docker images published to registry)
• Client (Angular 21 with Material UI)
• Server (Spring Boot 4 with Java 21)
• Authentication (Azure AD / MSAL)
• Configuration (Azure Key Vault, Spring profiles)
• AI integration (Anthropic Claude via Spring AI)
• AI mocking (Express mock server)
• Database (PostgreSQL with JPA)
• Testing (Playwright E2E)

Architecture

• client/ - Angular 21 SPA with Material UI, MSAL authentication
• server/ - Spring Boot 4 REST API with PostgreSQL, Spring AI
• mock_anthropic_server/ - Express mock for Claude API
• test/ - Playwright E2E tests
• scripts/ - Build and deployment scripts
• .github/workflows/ - CI/CD pipelines

Key Technologies

• Spring Boot 4.0.3, Java 21
• Angular 21.2.0
• PostgreSQL 17
• Spring AI 2.0.0-M2 (Anthropic)
• Azure AD (MSAL) authentication
• Azure Key Vault for secrets
• Traefik reverse proxy
• Docker multi-stage builds
• Playwright for E2E testing

Development Commands

Frontend

cd client && npm start        # Start dev server
cd client && npm run build    # Production build

Backend

cd server && mvn spring-boot:run -Dspring-boot.run.profiles=local  # Start with local profile

Testing

scripts/compose_up.sh         # Start test stack
cd test && npm test           # Run E2E tests
cd test && npx playwright test --ui  # Interactive test runner

API Routes

• GET /api/environment - Client configuration (public)
• GET /api/greeting - AI-powered greeting (authenticated)

Data Model

• greetings - Stores name and message used for AI greeting generation

Configuration Patterns

Spring Profiles

• prod - Production with Azure Key Vault and AAD
• local - Local development with Docker Compose DB
• test - Testing with disabled auth and mock AI services

Environment Config

• Server exposes /api/environment endpoint
• Client fetches config before bootstrap
• Conditionally enables MSAL based on mockAuth flag