Replace json_array with json type as requested by the deprecation

[Prometee]

Q	A
Branch?	1.9, 1.10
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
Related tickets	fixes #13211
License	MIT

doctrine/dbal:"^3" remove json_array field type, previously it was deprecated in favor of json field type.

[Prometee]

Their is still an issue with sylius_gateway_config table containing a remaining json_array type, we will have to wait for Payum/Payum#920 to be merged and released to fix this issue.

[vvasiloi]

Maybe add a constraint for doctrine/dbal for now?
I was surprised that "doctrine/orm": "^2.7" installed doctrine/dbal v3.

[Prometee]

@vvasiloi you are right it's the temporary fix, maybe another PR is required because I also think this PR will be needed in the futur when Payum/Payum#920 will be available.

[vvasiloi]

@Prometee yes, better do it in a separate PR with either an explicit require constraint, or a conflict.
This will also prevent the plugins without a composer.lock file (which are the most if not all) from breaking.

[Prometee]

@vvasiloi done !

#13215

[mbabker]

I was surprised that "doctrine/orm": "^2.7" installed doctrine/dbal v3.

Why? One of the main features of ORM 2.10 (which is already blocked on the 1.10 branch of this repo because of the gedmo/doctrine-extensions package being incompatible) is DBAL 3.x compatibility and DBAL 3.x should only be installed if all dependencies allow it. ORM 2.9 and earlier don't allow DBAL 3.x.

In general, Sylius' dependency declarations are really too loose IMO (in this repo, the standalone package repos, and the skeleton repos which these only declare sylius/sylius as their dependency (meaning out-of-the-box they rely on this repo to get the dependencies right) as a lot of direct dependencies seem to be not declared at all and things are relying heavily on transient dependencies to get it right (two practical examples include the dependencies on babdev/pagerfanta-bundle and jms/serializer-bundle but no declarations on pagerfanta/* or jms/serializer, which is where most of the code being used actually comes from).

[vvasiloi]

Maybe we should introduce Sylius to https://github.com/maglnet/ComposerRequireChecker?

[mmenozzi]

Maybe we should introduce Sylius to https://github.com/maglnet/ComposerRequireChecker?

@vvasiloi @mbabker Yes to avoid this kind of issues ComposerRequireChecker would be useful. Indeed I tried to introduce it in Sylius with #10664 2 years ago but the PR is still there, open and not reviewed.

[mmenozzi]

@vvasiloi @mbabker @Prometee note that even when this PR will be merged there will be also this issue with doctrine/dbal >= 3 and PHP 8: doctrine/migrations#1202

[vvasiloi]

@mmenozzi there's this PR #13215 that will add a conflict with doctrine/dbal >= 3 until all the issues are solved.

[mmenozzi]

@mmenozzi there's this PR #13215 that will add a conflict with doctrine/dbal >= 3 until all the issues are solved.

Yes I noticed it. Do you think that we should open an issue here to keep track of that?

[lchrusciel]

Hey Francis,

can you fix the build, remove dbal conflict and add one additional workflow to check if the new configuration works properly with dbal 2.10/2.9 and 3.0?

[Prometee]

Hi @lchrusciel,

I remove 1 commit about conflict and rebase the branch with the 1.9 one , but the build seems to fail because of another issue. (Nevermind it's failling because of payum/payum : https://github.com/Payum/Payum/blob/master/src/Payum/Core/Bridge/Doctrine/Resources/mapping/ArrayObject.orm.xml#L5)
When you said "add one additional workflow", you mean GitHub Action workflow ? I can't see any existing workflow doing what you asked for. Can you enlighten me ?

[Prometee]

Waiting for this PR : Payum/Payum#924 to be merged and released.

[maximehuran]

Hi,

On a fresh Sylus installation with MySQL 8, I have a database schema is not in sync with the current mapping file.

Here is the generated migration with a diff :

<?php

declare(strict_types=1);

namespace App\Migrations;

use Doctrine\DBAL\Schema\Schema;
use Doctrine\Migrations\AbstractMigration;

/**
 * Auto-generated Migration: Please modify to your needs!
 */
final class Version20220107153032 extends AbstractMigration
{
    public function getDescription(): string
    {
        return '';
    }

    public function up(Schema $schema): void
    {
        // this up() migration is auto-generated, please modify it to your needs
        $this->addSql('ALTER TABLE sylius_gateway_config CHANGE config config JSON NOT NULL');
    }

    public function down(Schema $schema): void
    {
        // this down() migration is auto-generated, please modify it to your needs
        $this->addSql('ALTER TABLE sylius_gateway_config CHANGE config config JSON CHARACTER SET utf8 NOT NULL COLLATE `utf8_unicode_ci` COMMENT \'(DC2Type:json_array)\'');
    }
}

FYI I have added this on my composer.json :

    "conflict": {
        "doctrine/dbal": "^3"
    }

[vvasiloi]

@lchrusciel the failed jobs don't seem to be related to the changes. Maybe we should restart the workflow.

[lchrusciel]

I've just restarted them.

Probably we should also allow dbal v3 with these changes. But that may be done in separate PR. Still, we need to have green build and composer is making some problems from what I see

[Prometee]

@lchrusciel yes I already retest it on my local env and all BeHat JS are green. I guess their is some weird network issue happening here. Restarting the build can help if it fails again...

[vvasiloi]

@lchrusciel all green.

[lchrusciel]

Thank you, Francis! 🎉

[lchrusciel]

TBH, I should just mention all of you. So thank you all Francis, Joseph, Victor, Manuele, Michael and Maxime for your work, comments, spotting problems etc :)

[vvasiloi]

@lchrusciel this should go to 1.11 and master too.

[lchrusciel]

I have some issues with upmerging atm. I've contacted @Zales0123 & @GSadee to do it, they should do it tomorrow morning. Also, we should release a new version of Sylius