Adding properties to existing doctrine entities - php

Question

I have the following design problem: I have two projects which both use doctrine to manage their entities. Both projects work on similar entities (most of them are in fact equal). I thought now it would be the best to write a library which contains the core entities used by both projects.
But this gives me more headaches than I first thought. Lets give you the following example, I have an entity
class Entity {
... a lot of managed properties used in both projects
}
then in project A i use exactly this entity, in project B my entity looks a little bit different:
class Entity {
... a lot of managed properties used in both projects
... one managed property only used in project B
}
Now if I declare Entity in my library I could extend it in my project B to add the additional property. But then the question is how to do it with doctrine. If I declare the entity in the library managed I can't easily declare the derived class as managed too in project B. On the other hand if I don't declare it managed in the library I won't be able to have associations containing the entity (which is in my case very important, I have a lot of associations across all my entities).
How should I handle such a situation? Writing the whole entity structure two times in both projects? It doesn't seem the right thing to do for me, but I can't think of another solution.

Answer 1

You could consider using traits that would contain sets of annotated properties and their related methods. This would give you the possibility to have a common base on which you can build both sides independently.
The down side is that both objects would not have a common interface, some of their internals would be the same but you would not be able to tell from the outside. A way to go around this would be to write an interface that exposes the methods you need to operate with those entities in your common library. The common trait could then take care of implementing that interface.
Edit: As you pointed out, traits are not very helpful if we are dealing with associations as you cannot override the targetEntity of an association with AssociationOverride annotation. That being said, by searching about that particular topic, I stumbled on the ResolveTargetEntityListener which might be the tool you were searching for.
The official documentation has a detailed page about how to use it (if you are using Symfony, there is this article as well). As explained in the documentation, thanks to that utility, you can have relationships between entities based on abstract classes or interfaces that would be resolved at runtime.
ResolveTargetEntityListener use with abstract classes
Here is a working example with abstract classes with the annotation MappedSuperClass:
AppBundle/Model/AbstractA.php
use Doctrine\ORM\Mapping as ORM;
/** #ORM\MappedSuperclass */
abstract class AbstractA
{
/**
* #ORM\Column(name="id", type="integer")
* #ORM\Id
* #ORM\GeneratedValue(strategy="AUTO")
*/
private $id;
/**
* #ORM\Column(name="text", type="string")
*/
private $text;
/** #ORM\ManyToOne(targetEntity="AppBundle\Model\AbstractB") */
private $b;
}
AppBundle/Model/AbstractB.php
/** #ORM\MappedSuperclass */
abstract class AbstractB
{
/**
* #ORM\Column(name="id", type="integer")
* #ORM\Id
* #ORM\GeneratedValue(strategy="AUTO")
*/
private $id;
/** #ORM\Column(name="number", type="integer") */
private $number;
}
AppBundle/Entity/A.php
/** #ORM\Entity() */
class A extends AbstractA {}
AppBundle/Entity/B.php
/** #ORM\Entity() */
class B extends AbstractB {}
And since I tested this with Symfony, I had to add the following in my config:
doctrine:
orm:
resolve_target_entities:
AppBundle\Model\AbstractA: AppBundle\Entity\A
AppBundle\Model\AbstractB: AppBundle\Entity\B
When asking doctrine for a schema update, it outputs:
CREATE TABLE a (id INT AUTO_INCREMENT NOT NULL, b_id INT DEFAULT NULL, text VARCHAR(255) NOT NULL, INDEX IDX_E8B7BE43296BFCB6 (b_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE b (id INT AUTO_INCREMENT NOT NULL, number INT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
ALTER TABLE a ADD CONSTRAINT FK_E8B7BE43296BFCB6 FOREIGN KEY (b_id) REFERENCES b (id);

Answer 2

That is a common and actually really good question. Lots of people are in trouble with such issues, and we cannot say that there is one and only one right answer to that.
I experienced various solutions, and the best I could "use" is to duplicate the entity(ies) definition(s) in each project.
Why ?
Because it is indeed easier to maintain, and even if you have some migration strategies (e.g. with Doctrine migrations or whatever), your code, relying on a specific version of the entities, could break.
You can try to deal with that kind of issues with a tool for migration strategies (i'm kinda out of the subject), and I'd then recommend to store every property (even the ones that are project-specific) in your library.
But do this if you really need it. Is it a big deal for you to duplicate ? Sometimes, factoring everything is not a good idea.
If you duplicate the definitions, you'll also be able to only focus on properties that you really care about. This means that some properties that you don't care about can be omitted from your entities definition in each project.
Just ensure that you still have a strategy for your migrations, it's always a good idea.