A third potential inheritance mapping strategy... is it valid?

[gravitiq-cm]

We have cases where we want to use inheritance when defining entities purely because there are common fields or functions for several entities. However, we do not want to use STI (where everything goes into one table) or CTI (where there are entries in multiple tables for a single entity). We want each child class to have its own table, which represents all the fields of that entity, no matter where they came from in the inheritance chain.

To me, this seems to give the benefits of inheritance and code reuse without the downsides of STI/CTI. Is there some reason why this is not considered a valid inheritance mapping strategy and is not supported in Doctrine?

[greg0ire]

Isn't that allowed with mapped superclasses?

[greg0ire]

I agree that it's confusing… mapped superclasses are documented just above.

I think everything inside and below the "entity inheritance" paragraph is about inheritance (direct or indirect) between 2 classes tagged with #[Entity]. It's not the case when using mapped superclasses, as you can see… there is PHP inheritance, but no Entity inheritance.

If you want to send a PR that changes https://github.com/doctrine/orm/blob/2.16.x/docs/en/reference/inheritance-mapping.rst, I think the first thing to do would be to change the headings so that STI and CTI are under Entity Inheritance.

Another thing you could contribute would be expanding the very first paragraph so that it mentions the distinction between the usage mapped superclasses, that involves PHP inheritance and nothing more, and entity inheritance.

[gravitiq-cm]

Wait... are you saying that the Entity Inheritance part does NOT apply to Mapped Superclasses?

I've been using Doctrine for a very long time (>10 years?) and always thought the Entity Inheritance part was linked to Mapped Superclasses as well (it was just more detail for the same concept).

The first sentence in the Entity Inheritance section even calls this out by mentioning Mapped Superclasses!

To paraphrase the first two paragraphs, it reads to me as "when entities inherit from other classes (inc Mapped Superclass) they form an inheritance hierarchy. The top entity is the root entity. On the root entity the InheritanceType (and other things) must be specified. [ie: you should declare InheritanceType for Mapped Superclasses and, further: if you're currently not declaring these things you're hacking around the edges of what's "correct" and may have unforeseen problems]"

[greg0ire]

I think your paraphrasing is plain wrong. Instead of paraphrasing anything, let me quote the docs with a little extra emphasis

As soon as one entity class inherits from another entity class, either directly, with a mapped superclass

So the top entity has to be... well... an entity. And a mapped superclass is not an entity AFAIK.

[gravitiq-cm]

One little word makes so much difference 😅

Thanks for clarifying! (and pointing out where I went wrong)

Would be great to find a way to clarify those docs, since there may be others misreading them the way I did. It does say on page that a Mapped Superclass is not an entity, but it wouldn't hurt to be clearer in the Entity Inheritance section. That sentence does continue to say "As soon as one entity class inherits from another entity class, either directly, with a mapped superclass..." so it's easy to miss that it only applies when there's a concrete Entity in the chain (as opposed to just extending a Mapped Superclass).

[greg0ire]

I agree… would you mind sending a pull request?

[derrabus]

we want to use inheritance when defining entities purely because there are common fields or functions for several entities.

Traits. ✌️

[gravitiq-cm]

https://www.doctrine-project.org/projects/doctrine-orm/en/2.16/reference/limitations-and-known-issues.html#using-traits-in-entity-classes

[gravitiq-cm]

Basically says "don't use traits to do this" [the scenario I described above]

[derrabus]

We should probably revisit that part of the docs. They should solve your problem and if they don't work in your scenario, we should make them work.

[beberlei]

The concept exists https://martinfowler.com/eaaCatalog/concreteTableInheritance.html

Implementation is also in Hibernate.

Its complicated, because it requires unions for querying the base tables and id generation is "tricky", because it sort of requires UUIDs or sequences.

[gravitiq-cm]

I'm not sure why it's complicated... there's a single table for each entity, so it manages its own IDs and sequences (as if it's not in an inheritance chain at all). In other words, the inheritance only exists in PHP-space, but not in the underlying database.

[beberlei]

If each table uses the same id for an entity, say ID 1 and you query for the base class, then you get 3 entities with the same ID from the same inheritance hierachy, leading to all sorts of "identity crisis" issues, notably in the code of Doctrine identity map for example.

Granted, you can find solutions for these problems, its just nobody bothered to implement this yet.