I think this is already solved in Search 6, but we need a test. Essentially the test would declare a mapped superclass and an entity type that extends it, with a "text" property in the mapped superclass, and would then declare programmatic mapping that targets the (inherited) "text" property on the entity type. If the schema is created as expected, then everything is ok.

See for example ImplementedInterfaceIT, which is very similar to what you'll need, but targets the JavaBean mapper. In your case you'll need a non-regression tests in the ORM mapper ITs.

About your third point. It's not entirely true.The programmatic API mapping and SearchMapping generally has not been designed to be a pivotal representation of the metadata. There might be work to be done to improve this model.

As it is today, annotations are a type safe model quite close to reality. We would need to duplicate that work and create an ad-hoc type-safe model for parsing. I did some experiments for Hibernate OGM. Check out and my local branch for some data. There is also an OGM pull request on the subject.

But such change would be of relatively low value compared to feature focused and value add to the user so I'm not sure we should prioritize this work today.

Dumping some thoughts I had when editing this issue:

• First of, talking about @MappedSuperclass in this context is misleading. Really the problem is entities in class hierarchies and the fact that using the programmatic API you cannot configure properties of super types in the EntityMapping of the sub type. This is partly caused by the fact that the programmatic API creates proxy annotations on the entity.

• Regarding the proxy annotation problem. One way to solve the problem would be to allow the configuration of super type properties as part of the sub type EntityMapping. In this case we would need to process the class hierarchy when placing the proxy annotations and place it on the right class. IMO, this would be more consistent with the way annotations works anyways

• A better approach, however, could be to turns things around. The _DocumentBuilder_s should process _SearchMapping_s instead of annotations. The annotation processing/parsing could then create _SearchMapping_s. The benefit I see is that we get a clearer separation of the reading of the annotation vs using this information to configure the _DocumentBuilder_s. Annotation processing becomes a two step process. IMO a big advantage.

You are correct, that would be a big departure. I'm not sure we can achieve that with the current way we parse things.

As far as I remember, programmatic API creates Annotations (with AnnotationFactory) and works like you annotate your Entities in your source.

ex:

So you have to...

As far as I know, per Entity Mapping is currently not possible. So if you have another Entity, ex 'Baz extends Foo', Baz inherits Foo mappings. The same for Embeddable classes.

It would be a nice if programmatic API could manage inherited properties (from MapperSuperclass and Embeddable) per Entity... but I'm afraid that this is a big change...

Please feel free to clarify if I'm wrong.