Searching on a numeric field that was indexed through an @IndexedEmbedded will return each and every document (i.e. the filter won't apply) for a [value TO *] query and will return no document for a [value1 TO value2] query. This happens when using the Hibernate Search DSL to build range queries.
I ran the test case in debug mode, and it seems that the problem starts here when building the query:
The problem is that fieldDescriptor is null for embedded fields, which makes the DSL fall back to some Infinispan-related magic, which doesn't consider Date to be a numeric indexed type. This is why the query becomes a keyword-range query ( ?) instead of a numeric-range query.
I searched around a little, and indeed it seems that this method, which initializes the field descriptors of a type descriptor, doesn't consider embedded fields:
The property descriptors don't include the embedded fields, since they are built that way:
... which won't do since the fieldMetadataSet on propertyMetadata doesn't include embedded fields.
I see two solutions:
1. Either we change the propertyMetadata so that it also includes a embeddedFieldsMetadataSet (and we initialize it, and we use it in createOrMergePropertyDescriptor())
2. OR we change IndexedTypeDescriptorImpl so that, in some way, it uses typeMetadata.getEmbeddedTypeMetadata() in the createAllFieldDescriptors() method.
Test case here : https://github.com/hibernate/hibernate-search/pull/958
Any (test case provided).
Added a link to the pull request with the test case.
Hey , thanks for the report and the thorough analysis!
IndexedTypeDescriptor et al. form a public meta-data API (which indeed does not appear to contain information on embedded fields), whereas TypeMetadata etc. are the internal meta-data model and provide the required information.
I am not quite clear why the DSL implementation doesn't use the internal API, maybe can shed some light on this? On first thought I'd say let's use the internal API. Exposing the embedded information in the public API would be nice, too, but it seems a separate issue which probably should better be addressed separately from fixing this bug.
Thanks for the pointers! I updated the pull request with a fix and rebased it to have a clean commit.
This is rather blocking for us so it would be nice if it could be integrated into a maintenance release with HSEARCH-2069.