Skip to content

Upgrade to doctrine/dbal:4#1872

Open
johanib wants to merge 1 commit intoupgrade-84from
feature/update_dbal_4_1799_3
Open

Upgrade to doctrine/dbal:4#1872
johanib wants to merge 1 commit intoupgrade-84from
feature/update_dbal_4_1799_3

Conversation

@johanib
Copy link
Contributor

@johanib johanib commented Oct 7, 2025

Needed for SF 6.4

@johanib johanib linked an issue Oct 7, 2025 that may be closed by this pull request
@johanib johanib moved this from New to In Progress in PHP development Oct 7, 2025
@johanib johanib mentioned this pull request Oct 7, 2025
5 tasks
@johanib johanib changed the base branch from upgrade to upgrade-84 October 8, 2025 07:33
@johanib johanib marked this pull request as ready for review October 8, 2025 08:27
@johanib johanib requested a review from MKodde November 3, 2025 08:42
Copy link
Member

@MKodde MKodde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! We had a small discussion IRL where I questioned the current solution:

  1. Could you make a more 'generic' solution for the object and array types that you now added. This would need to include passing the type of the array items that are stored for additional type checking. And maybe passing a max length as some types have different requirements for that..
  2. Keep the current setup but add some additional (unit or integration) tests. I've found a couple of unit tests for two of the existing types

Question: are the types used in the existing functional tests? Or are they bypassed by the custom mock solution?

@johanib johanib force-pushed the feature/update_dbal_4_1799_3 branch 2 times, most recently from 805c922 to 271256a Compare February 9, 2026 15:10
@johanib johanib force-pushed the feature/update_dbal_4_1799_3 branch from 271256a to cb43e68 Compare February 10, 2026 08:57
@johanib johanib force-pushed the feature/update_dbal_4_1799_3 branch from cb43e68 to fdc995d Compare February 10, 2026 10:10
@johanib johanib force-pushed the feature/update_dbal_4_1799_3 branch from fdc995d to 84b50bb Compare February 10, 2026 13:04
@johanib johanib requested a review from kayjoosten February 10, 2026 13:18
Copy link
Contributor

@kayjoosten kayjoosten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test are still failing

@github-project-automation github-project-automation bot moved this from In Progress to Backlog in PHP development Feb 13, 2026
@johanib johanib moved this from Backlog to In Progress in PHP development Feb 25, 2026
@johanib johanib force-pushed the feature/update_dbal_4_1799_3 branch from 6f86ba5 to 074c48f Compare February 25, 2026 14:20
@johanib johanib force-pushed the feature/update_dbal_4_1799_3 branch 4 times, most recently from b019847 to 29b6168 Compare February 26, 2026 10:22
@johanib
Copy link
Contributor Author

johanib commented Feb 26, 2026

Nice work! We had a small discussion IRL where I questioned the current solution:

  1. Could you make a more 'generic' solution for the object and array types that you now added. This would need to include passing the type of the array items that are stored for additional type checking. And maybe passing a max length as some types have different requirements for that..
  2. Keep the current setup but add some additional (unit or integration) tests. I've found a couple of unit tests for two of the existing types

Question: are the types used in the existing functional tests? Or are they bypassed by the custom mock solution?

  1. Yes, this was the correct way to go from the start. Implemented now.
  2. Also added tests for the two 'new' types.
  3. The behat tests fail if I omit the serialize, so yes, they are used in the behat tests.

@johanib johanib requested a review from MKodde February 26, 2026 10:30
@johanib johanib force-pushed the feature/update_dbal_4_1799_3 branch 3 times, most recently from 17fbd2f to dbadae3 Compare February 26, 2026 13:51
- The old array / object serialization types from doctrine have been moved / integrated into our codebase for backward compatability.

- Fix typo in allowed_idp_entity_ids. The db is a medium text, which is 16777215 bytes. This change aligns the column with the mapping.

- Make the nullable: false explicit to avoid future confusion. Confusion could stem from the fact that the fields are nullable in code, but not nullable in the database. This is because a serialized `null` results in something like `s:` in the database.
@johanib johanib force-pushed the feature/update_dbal_4_1799_3 branch from dbadae3 to b83392f Compare February 26, 2026 14:23
@johanib
Copy link
Contributor Author

johanib commented Feb 26, 2026

My earlier comparison was not correct. Doctrine does in fact want to remove the comments, and migrate longtext columns to json.
I split this into a separate PR, since it is not strictly needed, as long as we do not actually create and run the migrations.

#1917

In this PR, I reinstated the length limits so the correct column types are used matching prod. The nulls are also fixed.

@johanib johanib requested a review from MKodde February 26, 2026 14:56
#[Test]
public function an_object_round_trips_correctly(): void
{
$type = Type::getType(SerializedObjectType::NAME);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: spacing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

Upgrade to symfony 6.4

3 participants