Mapping and schema created by the migrations differ: process_schedule.input, log_record.process_execution_id, process_execution.context

[njoubert-cleverage]

Description

The schema created by the migrations of the bundle differs from the entity mapping on three columns:

• process_schedule.input: VARCHAR(255) in Version20240729151928, Types::TEXT in ProcessSchedule. With MySQL in strict mode (default), a schedule whose input is longer than 255 characters fails with Data too long for column 'input', while the mapping (and the form) allow it.

• log_record.process_execution_id: DEFAULT NULL in Version20231006111525, nullable: false in LogRecord.

• process_execution.context: NOT NULL in Version20241007152613, nullable: true in ProcessExecution (no failure today: ProcessExecution always sets at least []). Found after fix #97 Align process_schedule.input (VARCHAR(255) in the mapping) and log_record.process_execution_id (migration) #98 was merged.

All are reported by doctrine:schema:validate / doctrine:schema:update --dump-sql on an application whose schema was created by the migrations.

Reproduction

1. Create the schema with the migrations of the bundle (MySQL)
2. bin/console doctrine:schema:update --dump-sql: ALTER TABLE process_schedule CHANGE input input LONGTEXT DEFAULT NULL, ALTER TABLE log_record CHANGE process_execution_id process_execution_id INT NOT NULL, ...
3. Save a schedule with an input of 300 characters: ERROR 1406 (22001): Data too long for column 'input'

Expected: the schema created by the migrations matches the mapping.

Tested on main (001843b) in process-bundle-demo: MySQL 9.1, doctrine/dbal 4.5, doctrine/orm 3.7, PHP 8.5, Symfony 7.4.

Proposed fix

• process_schedule.input: keep VARCHAR(255) (the schedule input is a single-line value such as a file path) and fix the mapping instead: #[ORM\Column(length: 255, nullable: true)] No schema change (validating the length of the fields is a broader topic).

• log_record.process_execution_id: a new migration (MySQL / MariaDB, PostgreSQL) deleting the log records without process execution (never displayed by the UI) then making the column NOT NULL.

• process_execution.context (after fix #97 Align process_schedule.input (VARCHAR(255) in the mapping) and log_record.process_execution_id (migration) #98): made nullable in the same migration (Version20261005120000, never released).

The remaining differences ((DC2Type:...) column comments written by the migrations, useless since DBAL 4) are cosmetic and not handled here.

Requirements

• Documentation updates
  • Reference
  • Changelog
• Unit tests

Breaking changes

None. The log records without process execution, if any, are deleted by the migration.