Remove support for PHPDriver

[beberlei]

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";
    }
}

[darthf1]

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?

[morphles]

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?

[beberlei]

@darthf1 the alternative is to use the XML driver.

[ahundiak]

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.