Feature/add flyway migrations

[Ericthilen]

This PR introduces Flyway to manage database schema changes in a version-controlled way.

Previously, the project relied on Hibernate (ddl-auto=update) to automatically update the database schema. This approach can lead to inconsistencies between environments and makes it difficult to track schema changes.

Changes:

• Added Flyway dependencies
• Created migration folder: db/migration
• Added initial migration for assignee_id in ticket table
• Added foreign key constraint to staff
• Updated configuration:
• Replaced ddl-auto=update with ddl-auto=validate
• Enabled Flyway

Summary by CodeRabbit

• New Features

  • Tickets can now be assigned to staff members with enforced database relationships.

• Chores

  • Switched to explicit, versioned database migrations for schema changes and enabled migration execution at startup, replacing automatic schema updates.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 86f7f051-38b4-4b03-bc04-8e6745f9df93

📥 Commits

Reviewing files that changed from the base of the PR and between a1fca43 and 9e11238.

📒 Files selected for processing (1)

• src/main/resources/db/migration/V1__add_ticket_assignee.sql

✅ Files skipped from review due to trivial changes (1)

• src/main/resources/db/migration/V1__add_ticket_assignee.sql

---

📝 Walkthrough

Walkthrough

Adds Flyway to the project (pom), enables Flyway and switches Hibernate to validate mode (application.properties), and provides an initial SQL migration that adds a nullable assignee_id (BIGINT) column and a foreign key fk_ticket_assignee referencing staff(employee_id) on the ticket table.

Changes

Cohort / File(s)	Summary
Dependency Management pom.xml	Added org.flywaydb:flyway-core and org.flywaydb:flyway-database-postgresql dependencies.
Application Configuration src/main/resources/application.properties	Changed spring.jpa.hibernate.ddl-auto from update to validate; enabled Flyway with spring.flyway.enabled=true.
Database Schema Migration src/main/resources/db/migration/V1__add_ticket_assignee.sql	Adds nullable assignee_id (BIGINT) to ticket and creates foreign key constraint fk_ticket_assignee referencing staff(employee_id).

Sequence Diagram(s)

sequenceDiagram
  participant App as "Application\n(Startup)"
  participant Flyway as "Flyway\n(Migration Runner)"
  participant DB as "Database\n(Postgres)"
  participant Hibernate as "Hibernate\n(ORM Validator)"

  rect rgba(173,216,230,0.5)
    App->>Flyway: trigger migrations on startup
    Flyway->>DB: apply V1__add_ticket_assignee.sql
    DB-->>Flyway: migration success
  end

  rect rgba(144,238,144,0.5)
    App->>Hibernate: start and validate schema
    Hibernate->>DB: validate metadata vs. schema
    DB-->>Hibernate: validation result
    Hibernate-->>App: validation passed/failed
  end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Feature/assign ticket to staff #26 — Adds the assignee_id mapping on the Ticket entity and aligns the entity JoinColumn with this migration.

Suggested reviewers

• gitnes94
• alicewersen-rgb
• codebyNorthsteep

Poem

🐰
Flyway hops in at application start,
Adding a column, doing its part.
Hibernate checks with a cautious glance,
Tickets now carry a hopeful chance.
One small migration — a big little dance.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely summarizes the main change: introducing Flyway for database migration management, which is the core objective of this PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/add-flyway-migrations

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

src/main/resources/db/migration/V1__add_ticket_assignee.sql (1)

1-6: Consider baseline migration strategy for existing databases.

Since this project previously used ddl-auto=update, existing environments already have a schema. This V1 migration assumes the ticket and staff tables exist but doesn't account for the full initial schema. For fresh deployments or CI, you may need either:

1. A V0/baseline migration creating all existing tables, or
2. Use spring.flyway.baseline-on-migrate=true for existing databases

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/resources/db/migration/V1__add_ticket_assignee.sql` around lines 1 -
6, The V1__add_ticket_assignee.sql migration adds assignee_id and
fk_ticket_assignee but assumes existing ticket and staff tables; add guidance to
either supply a baseline migration (e.g., V0 that creates the existing schema
including ticket and staff) or enable Flyway baseline-on-migrate; update project
setup to include a baseline migration file that defines the initial tables
(ticket, staff, etc.) or document/enable spring.flyway.baseline-on-migrate=true
so Flyway will accept the current schema before applying
V1__add_ticket_assignee.sql.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/main/resources/db/migration/V1__add_ticket_assignee.sql`:
- Around line 4-6: The migration V1__add_ticket_assignee.sql is adding a foreign
key fk_ticket_assignee on ticket.assignee_id but references staff(id) which
doesn't exist; update the FOREIGN KEY reference to point to the actual PK column
name defined in the Staff entity (employee_id) so change REFERENCES staff(id) to
REFERENCES staff(employee_id), and verify ticket.assignee_id type matches
staff.employee_id; also re-run the migration or adjust the SQL if your
Staff.java `@Id` mapping changes.

---

Nitpick comments:
In `@src/main/resources/db/migration/V1__add_ticket_assignee.sql`:
- Around line 1-6: The V1__add_ticket_assignee.sql migration adds assignee_id
and fk_ticket_assignee but assumes existing ticket and staff tables; add
guidance to either supply a baseline migration (e.g., V0 that creates the
existing schema including ticket and staff) or enable Flyway
baseline-on-migrate; update project setup to include a baseline migration file
that defines the initial tables (ticket, staff, etc.) or document/enable
spring.flyway.baseline-on-migrate=true so Flyway will accept the current schema
before applying V1__add_ticket_assignee.sql.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 6a8fe192-95d1-4222-a202-38c069a2a379

📥 Commits

Reviewing files that changed from the base of the PR and between be2c8af and a1fca43.

📒 Files selected for processing (3)

• pom.xml
• src/main/resources/application.properties
• src/main/resources/db/migration/V1__add_ticket_assignee.sql