Open stof opened 2 years ago
I see 2 solutions there:
In any case, there needs to be a way to opt-in for the new driver behavior (as the drivers are currently inferred from the ORM driver being used)
And while this is done, it probably makes sense to do the same for the Yaml driver (but there, as the ORM Yaml driver is deprecated, it might make sense to go for just deprecating the Yaml driver too)
As the ORM has added a flat to turn on XSD validation in their 2.14 release and has deprecated the fact of keeping it disabled, this issue becomes much more relevant, as the current way to put the extension mapping inside the XML file of the ORM mapping would then fail with a XSD validation error.
copy this comment from https://github.com/doctrine-extensions/DoctrineExtensions/issues/2613#issuecomment-2188009498
Many projects use XML for ORM, and there are no plans to translate this into attributes. In the PR (https://github.com/doctrine-extensions/DoctrineExtensions/pull/2657) I proposed, there are two options for setting up Gedmo:
Also see PR in bundle: https://github.com/stof/StofDoctrineExtensionsBundle/pull/458
Currently, the XML mapping driver relies on adding custom elements inside the Doctrine XML mapping file itself. This relies on the fact that the Doctrine XML schema allows to add any node there. However, this is something that the ORM maintainers want to stop supporting. The 2.10.0 release removed that from the XSD. When I made them aware that
gedmo/doctrine-extensions
was impacted by that BC break, they agreed on reverting it in 2.10.2. However, I suspect that ORM 3.0 will still perform that BC break again.It would be wise for
gedmo/doctrine-extensions
to migrate away from this usage (in a backward-compatible way of course), to avoid being totally blocked by the time ORM 3.0 comes out.