[ https://issues.jboss.org/browse/ISPN-7842?page=com.atlassian.jira.plugin.... ] Yoann Rodière commented on ISPN-7842: ------------------------------------- Since I work on Hibernate Search, I feel the urge to give my two cents :) h4. Mising features # The index name seems to be missing; but maybe it's on purpose (you don't want the index name to be customized, nor two entities to share the same index)? # I think support for class bridges is missing (I guess {{<property type="class">}}, without a property name, would work, but it's hardly elegant). See {{org.hibernate.search.annotations.ClassBridge}} and {{org.hibernate.search.cfg.EntityMapping.classBridge(Class<?>)}} in Hibernate Search. # You need some way to assign analyzers to fields (e.g. {{property name="foo" analyzer="myAnalyzer"}}). See {{org.hibernate.search.annotations.Field.analyzer()}} and {{org.hibernate.search.cfg.FieldMapping.analyzer(Class<?>)}} in Hibernate Search. # As Sanne mentioned, analyzer definitions are absolutely necessary. You may think they don't belong in entity mappings (and I could not agree more), but they should be _somewhere_, so that you can reference the definitions when defining index fields (see above). # As Sanne mentioned, there should probably be some support for embedding other objects in an entity's index, though you could probably add it later. And yes, embedded objects may be mapped to index fields without having their own index (therefore the "indexed-entity-mapping" tag probably wouldn't be a good fit for those). See {{org.hibernate.search.annotations.IndexedEmbedded}} and {{org.hibernate.search.cfg.PropertyMapping.indexEmbedded()}} as well as {{org.hibernate.search.annotations.ContainedIn}} and {{org.hibernate.search.cfg.PropertyMapping.containedIn()}} in Hibernate Search. # As Sanne mentioned, custom field bridges (and custom class bridges, but that's about the same) are an important feature and should probably be supported from the start. See {{org.hibernate.search.annotations.Field.bridge()}} and {{org.hibernate.search.cfg.PropertyMapping.bridge(Class<? extends FieldBridge>)}} in Hibernate Search. h4. Unadvisable features # As Sanne mentioned, it would be best not to include index-time boost, since it will probably disappear soon. On top of that, I seem to remember it's buggy: if you contribute to the same index field from multiple properties, each time with the same boost, I believe the boost will grow exponentially with the number of contributing properties. So... you've been warned. h4. Cosmetics # {{<property name="name" type="method">}} "type" may not be a very explicit name... maybe "access-mode" would be better? # Unless there's a specific reason for that, the "mode" attribute on the "spatial" tag should probably accept lowercase values instead of {{HASH}} and such, so it'll be consistent with other attributes. Also, it's called "spatial-mode" instead of just "mode" when used at a property level; you may want to use the same attribute name in both cases. # The values for the "term-vector" attribute in the "field" tag should probably be "*true/false*/with-offsets/with-positions/with-position-offsets" to be consistent with "norms", "store", etc. h4. Index-driven mapping Also, I'd like to point out that while annotation-based mapping is necessarily entity-driven, XML-based mapping could be index-driven, which may arguably be clearer when contributing to the same index field from multiple entities : {code} <indexed-entities> <!-- annotated entity --> <indexed-entity>org.infinispan.query.queries.faceting.Car</indexed-entity> <!-- non-annotated entity --> <index-entity-mapping index-name="people"> <!-- the FQN of the class to index --> <indexed-entity id="author">my.domain.model.Author</class> <indexed-entity id="fan">my.domain.model.Fan</class> <!-- optional --> <spatial name="place" mode="HASH"> <bridge entity="author"> <!-- class bridge --> </spatial> <!-- list of index fields --> <field name="name" store="true" index="true" analyze="true" norms="true" term-vector="true"> <bridge entity="author" property="name" access-mode="method" impl="my.package.MyBridge"> <bridge entity="fan" property="fullName" access-mode="method"> </field> {code} Of course, it would be a bit confusing for users switching over from annotation-based mapping, and it also may be a bit more challenging to implement. You may not want to do this for various reasons, but I wanted to mention it, since that's probably not something you'll be able to change later. At least now you can knowingly dismiss the idea! -- This message was sent by Atlassian JIRA (v7.2.3#72005)