Fix XSD valdiation deprecation from ORM

[dmaicher]

See #1643

We need to agree on an approach so that users can get rid of the deprecation reported by the ORM

Using XML mapping driver with XSD validation disabled is deprecated and will not be supported in Doctrine ORM 3.0. (XmlDriver.php:60 called by SimplifiedXmlDriver.php:23, doctrine/orm#6728, package doctrine/orm)

[greg0ire]

Does the bundle allow to configure several XML drivers or just one? I'm wondering if there will be a global flag, or if it needs to be finer than that.

Also, I think the best default value for it will be %kernel.debug%, in which case I think we should remove the deprecation from the ORM entirely. I'm not sure what running this piece of code means if https://www.doctrine-project.org/schemas/orm/doctrine-mapping.xsd is not responding.

[stof]

Yes, you can have several drivers if you configure several mappings.

And the best value is not kernel.debug. If your project does not use external namespaces (like the gedmo extensions), the best value is true which disables the deprecated behavior.
If you use external namespaces, the only possible value is false (and putting the deprecation in the baseline) until you have solved that.

[dmaicher]

@greg0ire

Does the bundle allow to configure several XML drivers or just one? I'm wondering if there will be a global flag, or if it needs to be finer than that.

The bundle registers one XML driver per entity manager as far as I can tell: https://github.com/doctrine/DoctrineBundle/pull/1644/files#diff-afe5f060789287a8ad428a4b5df1ad844184f496ece0297e421f6b1fc442b5a4L1141

[greg0ire]

@stof I suggested using %kernel.debug% because I don't see the added value of running these checks in production, especially if that makes your production infrastructure dependent on doctrine-project.org: If you have the XSD mentioned as https://www.doctrine-project.org/schemas/orm/doctrine-mapping.xsd in your XML file, I suppose an http call is going to happen to that URL is going to happen at some point. What if it goes wrong?

[greg0ire]

Here is how Symfony handles this: symfony/symfony@a4adc3f 🤔

[ostrolucky]

We can use kernel.debug as default value, but I guess we still need to implement toggle which can disable deprecation in dev.

[stof]

@greg0ire the ORM project triggers a deprecation if you disable it.

especially if that makes your production infrastructure dependent on doctrine-project.org: If you have the XSD mentioned as https://www.doctrine-project.org/schemas/orm/doctrine-mapping.xsd in your XML file

The XML driver validates it against the local XSD file. It does not use xsi:location to discover the location of the XSD file. There is no HTTP call going on.

[greg0ire]

@greg0ire the ORM project triggers a deprecation if you disable it.

That can be changed.

The XML driver validates it against the local XSD file. It does not use xsi:location to discover the location of the XSD file. There is no HTTP call going on.

Oh right, I didn't remember implementing it like that 🤦

Indeed: https://github.com/doctrine/orm/pull/6728/files

In that case I guess we can go for true instead of %kernel.debug%, no harm done there.

[stof]

Fixed in 2.10.0 by exposing a new setting to opt-in for the new behavior.

[gjuric]

I have bundles that add custom Entities to the application by utilizing:

    $container->addCompilerPass(
        DoctrineOrmMappingsPass::createXmlMappingDriver($mappings)
    );

Is there a way to pass the validate_xml_mapping option to those entities as well?

[stof]

Not yet. I forgot about this feature. I will add support for that for the next version of the bundle.

[gjuric]

Should we reopen this issue so we can keep track on when this is added or maybe create a new one?