DBA migrations and postgres

[s3inlc]

This PR introduces two quite big changes to the backend:

• add support for PostgreSQL
• deprecate the update scripts and replace it with migrations using sqlx-cli (https://github.com/launchbadge/sqlx) in src/migrations/

Remarks for Users

• If possible, do not do multiple upgrade steps at once when upgrading to this newest version (upgrade to rainbow4 first). Updates from older versions should work, but there are higher changes if there is an issue during the upgrade, the manual fix is more complicated.
• The process is built to support upgrading pre-migrations MySQL databases and new setups with PostgreSQL. There is no automated way or guide provided to migrate an existing server from MySQL to PostgreSQL. This is technically possible, but needs more detailed knowledge of the DB and is only recommended for very experienced users.

Remarks for Developers

With migrations, there are some important points to take care of how updates to the database should be made and handled:

• NEVER ever do any change to a migration script which was released or lived on the main branch for a certain time. A change to an existing migration script will render setups which were done with the unaltered script into a intermediate state which cannot be fixed without manual intervention or deletion.
• For each "atomic" change on the database, e.g. for each new feature being created in a branch, a new migration script needs to be created (respecting the naming convention), in between each migration script, the database needs to be in a healthy and consistent state.
• A new migration scripts always needs to be provided for both MySQL and PostgreSQL in their directories respectively.
• On the merge of every PR where there is a new migration script added, we must ensure a correct order. This means that right before such a PR is merged, the script name MUST to be changed to the actual date prefix and committed into the branch of the PR!

[Copilot]

Pull request overview

This PR introduces major infrastructure changes to support PostgreSQL alongside MySQL and replaces the legacy update script system with a proper database migration framework using sqlx-cli.

Key Changes

• Added PostgreSQL database support with complete schema definitions
• Implemented sqlx-cli based migration system replacing manual update scripts
• Updated database connection handling to support multiple database types
• Modified Docker configurations and CI/CD workflows to support both MySQL and PostgreSQL

Reviewed changes

Copilot reviewed 25 out of 26 changed files in this pull request and generated 19 comments.

Show a summary per file

File	Description
src/migrations/postgres/20251127000000_initial.sql	Complete PostgreSQL schema with tables, indexes, and constraints - initial migration
src/migrations/mysql/20251127000000_initial.sql	MySQL schema reorganization for migration framework compatibility
src/inc/load.php	Added sqlx migration execution logic and removed legacy update system
src/inc/confv2.php	Enhanced configuration to support database type selection and default ports
src/dba/AbstractModelFactory.class.php	Updated getDB() to support both MySQL and PostgreSQL connections
src/dba/LikeFilter.class.php	Added database-specific LIKE query syntax for case-sensitive filtering
src/install/updates/update_v1.0.0-rainbow4_vx.x.x.php	Bridge script for migrating from legacy updates to sqlx migrations
docker-entrypoint.sh	Enhanced to detect and connect to both MySQL and PostgreSQL databases
docker-compose.postgres.yml	New PostgreSQL-based deployment configuration
docker-compose.mysql.yml	Updated MySQL deployment with database type specification
Dockerfile	Added sqlx-cli installation from Rust cargo
.github/workflows/ci.yml	Updated CI to test against both MySQL and PostgreSQL
.github/docker-compose.*.yml	Separate compose files for MySQL and PostgreSQL CI testing

Comments suppressed due to low confidence (1)

src/inc/load.php:86

• Security issue: Command injection vulnerability

The exec() call constructs a command using variables that may contain user input. The $database_uri variable includes DBA_USER, DBA_PASS, DBA_SERVER, DBA_PORT, and DBA_DB which could potentially contain shell metacharacters.

Recommendation: Use escapeshellarg() or escapeshellcmd() to properly escape the database URI and source path before passing them to exec(). Better yet, consider using a safer alternative like proc_open() with explicit argument arrays, or write credentials to a temporary config file that sqlx can read.

exec('/usr/bin/sqlx migrate run --source ' . dirname(__FILE__) . '/../migrations/' . DBA_TYPE . '/ -D ' . $database_uri, $output, $retval);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.