Hello, Currently, the medata definition mechanisms in Search work this way:
- the primary way to define metadata is using annotations - the secondary way to define metadata is programmatic, *but it only instantiates annotations,* simulating annotated entities - classes needing to access those "low-level" metadata (AnnotationMetadataProvider in particular) only manipulate annotations I'm wondering if we should change that, flipping the metadata definition upside-down: the programmatic definition would be the main one, with a clean, annotation-free low-level metadata model, and annotations would merely be translated to this low-level metadata using a walker and the programmatic API. My first argument is that creating "simulated" annotations is rather odd, but I'll grant you it's hardly receivable. But I can see other, more objective reasons: - We periodically notice missing methods in the programmatic API ([1], [2], [3], [4]), because we thought "annotations first" and forgot about the programmatic API. If annotation processing was to rely on programmatic mapping, this "annotations first" thinking would not be a problem anymore, but rather a good thing: we would have to implement both the programmatic API and the annotations in order to make it work. - If we want to support programmatic mapping for "free-form" (i.e. non-POJO) entities, we will need to be more generic than what annotations allow at some point. We already spotted the problem of using "Class<?>" to denote entity types, but there may be more. For instance denoting property identifiers, or property types, ... It just doesn't feel future-proof to rely on an intrinsically Java way of modeling metadata (the annotations) and try to model non-Java things with it... What do you think? Are there any objections to making the programmatic API the primary way to define metadata? Note that I'm not talking about making users use it in priority (it won't change anything for them), just about making it more central in our architecture. |1] http://stackoverflow.com/questions/43006746/hibernate-search-5-2-programmatic-configuration-of-facet-field [2] https://hibernate.atlassian.net/browse/HSEARCH-1764 [3] https://hibernate.atlassian.net/browse/HSEARCH-2199 [4] https://hibernate.atlassian.net/browse/HSEARCH-1079 Yoann Rodière <yo...@hibernate.org> Hibernate NoORM Team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev