First some context, we have issues open such as : = HSEARCH-1656 - Recognize annotations from implemented interfaces = HSEARCH-249 - Inheritance of annotations = HSEARCH-1231 - Discuss if @Indexed annotation should not be inherited by default
I've always felt it odd that we would ignore subtypes for @Indexed entities, but when mentioned I got excellent counter-arguments. Nowadays though I've mostly forgotten why we don't, and I'm wondering if those arguments still stand, especially as our position to issues like: HSEARCH-383 - Hibernate Search does not respect the @AccessType annotation in respect to @Id fields. is that we don't necessarily follow the same rules as Hibernate ORM. Also we're currently aiming at more flexible models, not least as needed by protobuf encoded models like in Infinispan Query, but we want of course to be consistent for users of Hibernate ORM. So questions: #1 Why don't we assume subclasses of an @Indexed entity is indexed as well? A comment in HSEARCH-1231 points out that this would need classpath scanning, but a) If it makes sense we should JFDI, or explore Jandex superpowers to help. b) I'm not sure anymore that we need that: in the ORM use case users won't be allowed to run CRUD operations on unknown entities anyway, so I think it's safe to assume that any entity passed to Search has been known by ORM (and passed to us at bootstrap). Am I wrong? The question stands for non-ORM use cases, but for example Infinispan Query needs to apply on-the-fly registration of new types as needed already: not a new problem there. #2 Is HSEARCH-1656 a good idea? I find the idea fascinating, but we'd need to apply strict validations against the usual problems of multiple inheritance. Many of our class-level annotations do not allow repetitions and we'd need to evaluate each of them to see if they would be valid if you "inherit" multiple of them. For example, multiple @ClassBridge annotations could result in a composition, but things like @DocumentId shall not be repeated, and I wonder if we should allow conflicting fieldname writes. Other annotations are supposed to represent a function (having a unique answer), like @AnalyzerDiscriminator: currently we mandate to have only one of them, which keeps things simple and understandable; if I have multiple discriminators defined (one on each interface), would you expect the function to be applied independently on the @Field(s) defined by that interface? As someone defining different (independent) interfaces I would expect that, as I might not know about someone putting both (more) interfaces on a single concrete implementation, and probably the other annotations of each interface are expecting that specific AnalyzerDiscriminator to be applied to them. #3 Are #1 and #2 unrelated? I suspect they are not, IMHO if we do inheritance of annotations, inheriting them from interfaces is the next natural and consistent step. Or not? So it would be important to evaluate their link before committing on either, as it seems both have consequences. #4 Any example of inconsistent experience for ORM users to handle our inheritance "differently"? *differently* is a biased term though as it suggests some violation of least surprise, but actually as a user myself and as I think suggested by various other users as well, while the ORM rules are clear this missing inheritance in Search seems to have been a surprise to many. I suspect people understand the two things are quite different and we should pick a consistent rule (like decide to reject HSEARCH-383 ?) Thanks a lot for any feedback, Sanne https://hibernate.atlassian.net/browse/HSEARCH-1656 https://hibernate.atlassian.net/browse/HSEARCH-249 https://hibernate.atlassian.net/browse/HSEARCH-1231 https://hibernate.atlassian.net/browse/HSEARCH-383 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
