Remove support for PHPDriver #6893

Closed
opened 2026-01-22 15:40:50 +01:00 by admin · 6 comments
Owner

Originally created by @beberlei on GitHub (Dec 20, 2021).

Q A
New Feature yes
RFC no
BC Break yes/

Summary

We should deprecate and remove the PHPDriver, because using a magic variable $metadata in a file is confusing and the StaticPHPDriver offers a better API with a method on the entity. This will reduce the amount of test-code we have to maintain significantly.

Users can use the orm:convert-mapping command in the 2.* branches to move to another mapping driver without great effort.

In addition if they want to stay with programmatic metadata configuration, StaticPHPDriver could be used in a simple way to keep the old mapping:

class City
{
    public static function loadMetadata(ClassMetadata $metadata)
    {
        include "path/to/mapping/City.php";
    }
}
Originally created by @beberlei on GitHub (Dec 20, 2021). | Q | A |------------ | ------ | New Feature | yes | RFC | no | BC Break | yes/ ## Summary We should deprecate and remove the PHPDriver, because using a magic variable `$metadata` in a file is confusing and the StaticPHPDriver offers a better API with a method on the entity. This will reduce the amount of test-code we have to maintain significantly. Users can use the `orm:convert-mapping` command in the 2.* branches to move to another mapping driver without great effort. In addition if they want to stay with programmatic metadata configuration, `StaticPHPDriver` could be used in a simple way to keep the old mapping: ```php class City { public static function loadMetadata(ClassMetadata $metadata) { include "path/to/mapping/City.php"; } } ```
admin added the ImprovementDeprecation labels 2026-01-22 15:40:50 +01:00
admin closed this issue 2026-01-22 15:40:50 +01:00
Author
Owner

@darthf1 commented on GitHub (Jan 4, 2022):

Let me start by saying that I completely understand why wou would want to remove/delete this, when having the StaticPHPDriver as an alternative.

In my codebase, I'm having my domain code and infrastructure code separate. This means that my domain model lives in my Domain namespace, and if that model is also a doctrine entity, theres a domain.model.php in my Infrastructure namespace somewhere with the magic $metadata variable.

Reading the documentation of the StaticPHPDriver, the loadMetadata function needs to reside inside the entity class, which means it wont be possible to separate these two anymore (with php).

Whilst deprecating/removing the PHPDriver, is it possible to allow the separation of the entity and the mapping for the StaticPHPDriver?

@darthf1 commented on GitHub (Jan 4, 2022): Let me start by saying that I completely understand why wou would want to remove/delete this, when having the `StaticPHPDriver` as an alternative. In my codebase, I'm having my domain code and infrastructure code separate. This means that my domain model lives in my `Domain` namespace, and if that model is also a doctrine entity, theres a `domain.model.php` in my `Infrastructure` namespace somewhere with the magic `$metadata` variable. Reading the [documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/php-mapping.html#static-function) of the `StaticPHPDriver`, the `loadMetadata` function needs to reside inside the entity class, which means it wont be possible to separate these two anymore (with php). Whilst deprecating/removing the `PHPDriver`, is it possible to allow the separation of the entity and the mapping for the `StaticPHPDriver`?
Author
Owner

@morphles commented on GitHub (Feb 21, 2022):

Just out of curiosity, cause it seems just super counterproductive to me (and even other drivers too), @darthf1 why would you want to separate mapping from entity?

@morphles commented on GitHub (Feb 21, 2022): Just out of curiosity, cause it seems just super counterproductive to me (and even other drivers too), @darthf1 why would you want to separate mapping from entity?
Author
Owner

@beberlei commented on GitHub (Feb 21, 2022):

@darthf1 the alternative is to use the XML driver.

@beberlei commented on GitHub (Feb 21, 2022): @darthf1 the alternative is to use the XML driver.
Author
Owner

@ahundiak commented on GitHub (Mar 31, 2022):

Kind of a shame that the PHPDriver is going away. One thing it allowed was to group the mapping files into one directory while at the same time the entities could live wherever they wanted. You could organize your code by feature. And yes putting your entities in entity specific directories is the norm but it is a bit restrictive.

Looking forward to ORM 3's release. Maybe some clever coder can tweak the xml mapping stuff to support php thus removing the testing burden from the core group.

@ahundiak commented on GitHub (Mar 31, 2022): Kind of a shame that the PHPDriver is going away. One thing it allowed was to group the mapping files into one directory while at the same time the entities could live wherever they wanted. You could organize your code by feature. And yes putting your entities in entity specific directories is the norm but it is a bit restrictive. Looking forward to ORM 3's release. Maybe some clever coder can tweak the xml mapping stuff to support php thus removing the testing burden from the core group.
Author
Owner

@morphles commented on GitHub (Mar 31, 2022):

IMO StaticPHP is undoubtedly best driver of them all. Not needlessly separating definitions, allowing to use basic PHP stuff, like constant for discriminator map etc. Not needing to learn/know some new format. All round way better than anything else, just documentation sucks. :(

@morphles commented on GitHub (Mar 31, 2022): IMO StaticPHP is undoubtedly best driver of them all. Not needlessly separating definitions, allowing to use basic PHP stuff, like constant for discriminator map etc. Not needing to learn/know some new format. All round way better than anything else, just documentation sucks. :(
Author
Owner

@derrabus commented on GitHub (May 11, 2022):

Closed via #9309, #9308.

@derrabus commented on GitHub (May 11, 2022): Closed via #9309, #9308.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6893