We have an inheritance hierarchy that we're trying to implement. It's a hierarchy that really could have been best served using multiple inheritance. Since that's not possible we've modelled one of the inheritance chains by just putting all of the related fields onto the base class. This of course has the undesired effect that there are some fields now on the base class that we don't want on the inherited entities. One possible solution to our problem would be to have the ability to mark some fields as being "protected". That way we could "hide" the fields on the subclasses. In fact it means that if we were to present the second dimension of inheritance as various interfaces, the implementation of the interface could expose these protected properties as appropriate and they would theoretically still be persisted. This might not be possible since the adapter may then not be able to access the protected properties to persist them.

And how are you going to set the fields to a new value?

Inheritance isn't always the best solution. With databases, you've to be careful not to overdo inheritance, as you might run into the issue where you have to join a couple of tables every time you run a query. It's often more performant (and doesn't really matter due to the 1:1 relation so no code duplication) to opt for a related entity instead.

I understand that you need to be judicious with the use of inheritance, however this is a specific case where inheritance does indeed make sense (at least it does to us). And the one place in our model where multiple inheritance makes sense too. (We're abstracting a storage mechanism in one dimension and object meta data in the other). In the case we're talking about, the cost should be identical whether 1:1 related entities or inheritance. (I think polymorphic fetches with left-joins are the primary source of potential performance issues right? That and long chains of subclasses).

Inheritance in this case just makes the code easier.

Anyway, our case is a minority case so I'm not too fussed if you think this is not something that should be in the product. Indeed, using protected properties to "hide" properties from certain subclasses is a work-around, not a clean solution. What we'd actually want is mutiple inheritance with a mixture of entity-per-type and entity-per-type-hierarchy for that inheritance structure - both of which are not possible. In the protected property case, to get and/or set fields, we'd have to derive from the llblgen entities and write properties in those derived classes to expose the specific protected base properties for the subtypes. This would essentially be emulating entity-per-type-hierarchy (via interface and protected properties) within a standard entity-per-type inheritance model.

ie create a standard entity-per-type inheritance model for the first inheritance dimension then for the other dimension, add all of the fields to the base entity, create interfaces for the second dimensions "subclasses" and then subclass each of the first dimensions classes implementing the appropriate interface from the second dimension - which exposes the appropriate fields from the base entity.

Don't worry. We'll deal with this another way.

Hi,

have you got some experience with prefetch paths and inner collection/entity properties?

By moving from an inheritance paradigm to a components paradigm, you may just be fine and have no need to create extra properties.

That's what a potential need for multiple inheritance suggests to me. The various children entities may well be components of the base one. Then they may in turn be in their own distinct inheritance hierarchies.

Cheers

Certainly we have experience with prefetch paths, however I have not yet used (nor yet seen a use for – until now) the fields mapped on related fields feature. Indeed this is an alternative that will pretty much achieve what I want to achieve. And right under my nose too

Thank you very much!