Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Incompatibility with Symfony 4.3.10+ #616

Closed
excentrik opened this issue Feb 14, 2020 · 2 comments
Closed

Incompatibility with Symfony 4.3.10+ #616

excentrik opened this issue Feb 14, 2020 · 2 comments

Comments

@excentrik
Copy link

excentrik commented Feb 14, 2020 •
edited

Hello

In our company's project we are currently using Symfony 4.4 branch, but we are still behind in our move towards using Doctrine ODM 2.

Therefore we still rely on doctrine/mongodb-odm-bundle for the interface beween Symfony and doctrine odm 1.3.

Unfortunately, the PR symfony/symfony#34955 has broken interface compatibility between the doctrine/mongodb-odm-bundle and Symfony's latest versions (4.4.2+,4.3.10+,5.0.2+):

PHP Fatal error:  Declaration of Doctrine\Bundle\MongoDBBundle\Form\Type\DocumentType::getLoader(Doctrine\Common\Persistence\ObjectManager $manager, $queryBuilder, $class) 
must be compatible with Symfony\Bridge\Doctrine\Form\Type\DoctrineType::getLoader(Doctrine\Persistence\ObjectManager $manager, $queryBuilder, $class)

Since the interface is almost the same, I think the fix should be just changing the method Doctrine\Bundle\MongoDBBundle\Form\Type\DocumentType::getLoader to receive a Doctrine\Persistence\ObjectManager but I'm not sure if this would cause any other incompatibilities.
excentrik added a commit to Rohea/DoctrineMongoDBBundle that referenced this issue Feb 14, 2020
@excentrik
Fix Symfony 4.3.10+ interface compatibility
abfe32c 
Upstream issue: doctrine#616
@greg0ire
Copy link
Member

Hi! Thanks for reporting this. The issue is not with this bundle though, it is with Symfony (more exactly, the DoctrineType class). I'm going to work on a PR rightaway, and link to this issue in it, you should see the PR link pop here when I am done.

greg0ire added a commit to greg0ire/symfony that referenced this issue Feb 14, 2020
@greg0ire
Add missing autoload calls
8551073 
Until either php 7.4 or doctrine/persistence 2 is required, these will
be needed to make sure php recognises signatures using the old names as
compatible with signatures using the new names.
This is necessary for types defined outside Symfony that extend types
from Symfony and still use the old names in signatures of methods they
override.

Fixes doctrine/DoctrineMongoDBBundle#616
@greg0ire greg0ire mentioned this issue Feb 14, 2020
Merged
greg0ire added a commit to greg0ire/symfony that referenced this issue Feb 14, 2020
@greg0ire
Add missing autoload calls
2a40ba8 
Until either php 7.4 or doctrine/persistence 2 is required, these will
be needed to make sure php recognises signatures using the old names as
compatible with signatures using the new names.
This is necessary for types defined outside Symfony that extend types
from Symfony and still use the old names in signatures of methods they
override.

More details at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

Fixes doctrine/DoctrineMongoDBBundle#616
greg0ire added a commit to greg0ire/symfony that referenced this issue Feb 14, 2020
@greg0ire
Add missing autoload calls
94b5dbd 
Until either php 7.4 or doctrine/persistence 2 is required, these will
be needed to make sure php recognises signatures using the old names as
compatible with signatures using the new names.
This is necessary for types defined outside Symfony that extend types
from Symfony and still use the old names in signatures of methods they
override.

More details at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

Fixes doctrine/DoctrineMongoDBBundle#616
greg0ire added a commit to greg0ire/DoctrineMongoDBBundle that referenced this issue Feb 14, 2020
@greg0ire
Address deprecations from persistence library
7983394 
A backwards-compatibility layer has been added to persistence to help
consumers move to the new namespacing. It is based on class aliases,
which means the type declaration changes should not be a BC-break: types
are the same.
See doctrine/persistence#71

This means:
- using the new namespaces
- adding autoload calls for new types to types that may be extended and
use persistence types in methods signatures for which compatibility
checks may happen,
so that signature compatibility is recognized by old versions of php.
More details on this at
https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

Fixes doctrine#616 as a side effect, but the real fix is at
symfony/symfony#35728
@greg0ire greg0ire mentioned this issue Feb 14, 2020
Merged
greg0ire added a commit to greg0ire/DoctrineMongoDBBundle that referenced this issue Feb 14, 2020
@greg0ire
Address deprecations from persistence library
4d5593f 
A backwards-compatibility layer has been added to persistence to help
consumers move to the new namespacing. It is based on class aliases,
which means the type declaration changes should not be a BC-break: types
are the same.
See doctrine/persistence#71

This means:
- using the new namespaces
- adding autoload calls for new types to types that may be extended and
use persistence types in methods signatures for which compatibility
checks may happen,
so that signature compatibility is recognized by old versions of php.
More details on this at
https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

Fixes doctrine#616 as a side effect, but the real fix is at
symfony/symfony#35728
greg0ire added a commit to greg0ire/DoctrineMongoDBBundle that referenced this issue Feb 14, 2020
@greg0ire
Address deprecations from persistence library
2aa6500 
A backwards-compatibility layer has been added to persistence to help
consumers move to the new namespacing. It is based on class aliases,
which means the type declaration changes should not be a BC-break: types
are the same.
See doctrine/persistence#71

This means:
- using the new namespaces
- adding autoload calls for new types to types that may be extended and
use persistence types in methods signatures for which compatibility
checks may happen,
so that signature compatibility is recognized by old versions of php.
More details on this at
https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

Fixes doctrine#616 as a side effect, but the real fix is at
symfony/symfony#35728
fabpot added a commit to symfony/symfony that referenced this issue Feb 15, 2020
@fabpot
bug #35728 Add missing autoload calls (greg0ire)
9697e9d 
This PR was merged into the 4.4 branch.

Discussion
----------

Add missing autoload calls

Until either php 7.4 or doctrine/persistence 2 is required, these will
be needed to make sure php recognises signatures using the old names as
compatible with signatures using the new names.
This is necessary for types defined outside Symfony that extend types
from Symfony and still use the old names in signatures of methods they
override.

Fixes doctrine/DoctrineMongoDBBundle#616

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | yes
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       | Fix doctrine/DoctrineMongoDBBundle#616
| License       | MIT
| Doc PR        | n/a
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.

Additionally (see https://symfony.com/releases):
 - Always add tests and ensure they pass.
 - Never break backward compatibility (see https://symfony.com/bc).
 - Bug fixes must be submitted against the lowest maintained branch where they apply
   (lowest branches are regularly merged to upper ones so they get the fixes too.)
 - Features and deprecations must be submitted against branch master.
-->
This topic is fairly complicated, more details at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

Commits
-------

94b5dbd Add missing autoload calls
symfony-splitter pushed a commit to symfony/doctrine-bridge that referenced this issue Feb 15, 2020
@greg0ire
Add missing autoload calls
bceef1a 
Until either php 7.4 or doctrine/persistence 2 is required, these will
be needed to make sure php recognises signatures using the old names as
compatible with signatures using the new names.
This is necessary for types defined outside Symfony that extend types
from Symfony and still use the old names in signatures of methods they
override.

More details at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

Fixes doctrine/DoctrineMongoDBBundle#616
Hakihiro pushed a commit to Hakihiro/symfony that referenced this issue Feb 17, 2020
@greg0ire
Add missing autoload calls
0fa652f 
Until either php 7.4 or doctrine/persistence 2 is required, these will
be needed to make sure php recognises signatures using the old names as
compatible with signatures using the new names.
This is necessary for types defined outside Symfony that extend types
from Symfony and still use the old names in signatures of methods they
override.

More details at https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

Fixes doctrine/DoctrineMongoDBBundle#616

Fix retour pr
@excentrik
Copy link
Author

@greg0ire Thank you for the swift reply and fixes. Hopefully symfony 4.4.5 is released soon 😄

greg0ire added a commit to greg0ire/DoctrineMongoDBBundle that referenced this issue Mar 15, 2020
@greg0ire
Address deprecations from persistence library
ce5f39b 
A backwards-compatibility layer has been added to persistence to help
consumers move to the new namespacing. It is based on class aliases,
which means the type declaration changes should not be a BC-break: types
are the same.
See doctrine/persistence#71

This means:
- using the new namespaces
- adding autoload calls for new types to types that may be extended and
use persistence types in methods signatures for which compatibility
checks may happen,
so that signature compatibility is recognized by old versions of php.
More details on this at
https://dev.to/greg0ire/how-to-deprecate-a-type-in-php-48cf

Fixes doctrine#616 as a side effect, but the real fix is at
symfony/symfony#35728
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@greg0ire @excentrik