Why no other Polimorphic association than Inheritance Mapping?

[Eliepse]

Hello everyone,

I'd like to start this discussion to exchange about Doctrine and a Polymorphism association that does not rely on inheritance or other way it could be done with Doctrine as we speak today. There already has been some discussion around the subject, but not on "why", mostly on "how to implement it" (see "Related discussion below").

This discussion is not a request to support the type of polymorphism that I will develop below, but to have a better idea on the various reason why it won't be implemented.

The "two column" polymorphism

Not sure it has a more official name, but this kind of polymorphism consist on two columns that reference the parent: a column to reference the ID and a column to reference the Type of the related parent. You can find an explanation on the documentation of Laravel, but I'll replicate there example below:

Consider three entities: Post, User and Image. The idea is that both Post and User can have an image association.
To map the association, the table of the entity Image has a column imageable_id that reference the ID of the related entity, and a column imageable_type that reference the type of the related entity. Laravel even use the fully qualified class name as the type in order to be able to instantiate the related model without having to give any additional mapping on the code.

post
    id - integer
    name - string
 
user
    id - integer
    name - string
 
image
    id - integer
    url - string
    imageable_id - integer
    imageable_type - string

Pros

• Flexibility of the related types (no need to update the schema)
• A single table (unlike Class Table Inheritance)
• No columns specific to a single child class (unlike Single Table Inheritance)
• An index can be used to optimize queries
• Easy to manipulate with SQL

Cons

• No foreign key (Cascade and Restict has to be managed elsewhere or with SQL triggers/Constriants)
• Adds complexity to the ORM and Schema (see Related discussion)

There are probably more Pros/Cons that I forgot or haven't see, comments about it are welcome as it can fall right in the "why won't it be implemented?"

How about Doctrine STI and CTI ?

As stated in the Doctrine documentation, Single Table Inheritance (STI) and Class Table Inheritance (CTI) have both some problems. First, they both require to extends classes from a "root" one. It's interesting for a small sized project, but on larger application it quickly start to be problematic as you would require to extends many classes if not all, and have chained extends if you want to support different inheritance mapping (would it be even possible?). It adds a lot of complexity on the application and makes it hard to maintain.

On the database side, it creates other problems like having many columns on a single table that a only dedicated to some entites diagram, or a complex table/extended table relationship that makes the structure hard to understand diagram.

Related discussions

Issue: Support for polymorph association through interfaces

My opinion is that this is a no go, it adds a unnecessary complexity to the ORM and to the schema without adding a huge benefit on design.

Not sure how it would be more complicated than Inheritance mapping (especially for the schema). Does it means that the reason is that it's too difficult to implement it on the actual code base of the ORM ?

StackOverflow: Doctrine polymorphic association
StackOverflow: Reflect MySQL polymorphic association in Doctrine 2.2

Why no implementation?

The question that I have is, what are the reasons that prevent Doctrine from implementing such a type of association? Is it too complicated to implement with the actual Doctrine codebase? Is it a divergence between this type of association and the vision shared in the Doctrine project?

Whatever it is, I believe Doctrine would benefit from support more variety of associations. As always, it's up to the developer to select the best way to do something.

What are your thoughts about it? Even if you didn't know about this type of association, your input is interesting. :)

[NotionCommotion]

Hi Eliepse,

Other than a given Image belonging to a given Post or User, is there anything different about the Image? Could they have different properties? I don't know much if anything about Laravel, however, a quick look shows that it doesn't have the concept of entities, but uses models instead.

class Image extends Model
{
    public function imageable()
    {
        return $this->morphTo();
    }

    public function morphTo($name = null, $type = null, $id = null, $ownerKey = null)
    {
        // do a bit of work.
        return new MorphTo($query, $parent, $foreignKey, $ownerKey, $type, $relation);
    }
}

class Post extends Model    // User similar
{
    public function image()
    {
        return $this->morphOne(Image::class, 'imageable');
    }

    public function morphOne($related, $name, $type = null, $id = null, $localKey = null)
    {
        // do a bit of work.
        return new MorphOne($query, $parent, $type, $id, $localKey);
    }
}

Also, potentially this could be implemented with your own PHP code. Or maybe there is some existing package that does so? I looked at Symfony's ACL solution a while back and they do something similar.

I agree that this topic needs more discussion and that CTI and STI bring their own challenges, but it also seems that table inheritance and two column polymorphism are not necessarily substitutes for one another.

[Eliepse]

Hey, thank you for your contribution!

Other than a given Image belonging to a given Post or User, is there anything different about the Image? Could they have different properties?

Well they could, but if the difference is not significant it often worth having one or two extra columns that having two or three tables almost identical, and having to union join all the time.

I'm not sure to fully get the difference between an architecture made of Models and one of Entities. Aren't Symfony and Laravel both based on Model-View-Controller principle? Maybe in the fact Laravel doesn't build a schema and migration from Models, and requires to write the migrations by hand.

Also, potentially this could be implemented with your own PHP code. Or maybe there is some existing package that does so? I looked at Symfony's ACL solution a while back and they do something similar.

Yes, in deed it's achievable by hand. But we could say the same for all associations that are automatically handled by Doctrine (schema definition, lazy loading, orphan removal, etc). If this association method was to be implemented, it should benefit of the same praticality. 😃

I agree that this topic needs more discussion and that CTI and STI bring their own challenges, but it also seems that table inheritance and two column polymorphism are not necessarily substitutes for one another.

Yes, they serve different problems. I didn't know about them before working on a Symfony based project and it's really useful on some cases. Not sure it's supported by Laravel.

[mpdude]

You can probably do this by having the image refer to a base entity class in Doctrine, and have post and user as subclasses of that base entity. That would not give the exact database schema, tough, but bring the flexibility that the image may refer to either a post or user at the end of the day.

How could such an association work from the image side? What about eager loading? Consider this DQL:

SELECT i, t FROM image i JOIN i.imageable t

The expectation would be to load all images, and have the imageable association eager loaded. For every single image, we'd need to initialize either a post or an user? To do that, Doctrine would have to LEFT JOIN (in SQL) both tables and pick columns from the right one – for every row – depending on the value of imageable_type? To make it even more complex, what would happen when one of those entities is using inheritance and has, for example, JTI?

Oh, and what about queries like

SELECT i, t FROM image i JOIN i.imageable t WHERE t.createdAt <= :date

Here, I'd like to find all images that have an associated post or user, and where the createdAt field matches a condition. The createdAt field, in fact, comes from two different tables, and which one we'd have to look at depends on the value of the imageable_type column for every single row.

[timching]

I have had similar issues recently, and I think it's too easy to do sth like this in doctrine? and not to implement this to ORM can keep the flexibility?

since what we need to do is just add those fields and use the following piece of code

post
    id - integer
    name - string
 
user
    id - integer
    name - string
 
image
    id - integer
    url - string
+    imageable_id - integer
+    imageable_type - string

the piece of (pseudo) code

// or even uuid should works, of coz should update datatype of this field
$imageable_id = $image->getImageableId();
// assume store the class name to db, and as I rmb Laravel also store the Model class name in db, correct me if I'm wrong
$imageable_class = $image->getImageableType();

$imageable_entity = $entityManager->getRepository($imageable_class)->find($imageable_id);
// of coz this will be another SQL to retrieve,
// but for these structure it's better to lazy load instead of any kind of table join I believe?

reference (doctrine/persistence)
https://github.com/doctrine/persistence/blob/b337726451f5d530df338fc7f68dee8781b49779/src/Persistence/ObjectManager.php#L107
https://github.com/doctrine/persistence/blob/b337726451f5d530df338fc7f68dee8781b49779/src/Persistence/ObjectRepository.php#L24

[Eliepse]

Hey,
Thanks for you proposition. It is an interesting one for sure and I will probably use it.