Report incomplete metadata issues during Elasticsearch mapping generation
Description
Activity
Yoann Rodière November 9, 2016 at 4:16 PM
There was one right in the code snippet:
And it's actually the only case I can think of. So it would be when:
A given field has a field bridge
This field bridge does not use (nor provide metadata for) the default field name
org.hibernate.search.engine.metadata.impl.AnnotationMetadataProvider.determineNumericFieldEncoding(FieldBridge) fails to determine the numeric encoding
org.hibernate.search.engine.metadata.impl.AnnotationMetadataProvider.isNumericField(NumericField, FieldBridge) returns true
If that happened, there would be a numeric field with unknown encoding, and generating the mapping for such field is impossible.
Now that I think of this, though, I wonder if this can even happen... I mean, this would require someone to put an @Numeric annotation on his field and to use a custom field bridge.
Before we fixed that was a valid use case, because it was about the only way to make the default field numeric when using a custom field bridge. Now, though, it doesn't seem useful at all.
Anyway, the comment above is not mine, so I'm not 100% sure why it was added. Here is the commit: https://github.com/hibernate/hibernate-search/commit/1450f9dd385ce810a09365beec02deba387d03af#diff-09eccad1a2093907e2d873d3193a4be7R309 I'd say maybe can help, but I doubt it given it's almost 1 year old...
If we decide that it's not useful anymore, then the solution to this ticket would simply throw an exception.
Guillaume Smet November 9, 2016 at 1:30 PM
Could you give us an example of a case where this error would be considered normal?
Details
Details
Assignee
Yoann RodièreReporter
Yoann RodièreComponents
Fix versions
Priority
Minor
Issue spotted here: https://github.com/hibernate/hibernate-search/pull/1217/commits/dfc7f199358808397d144d79d89f7915851db222#r87074164
Right now, we're only logging debug messages when failing to add a property/field to the ES mapping:
The only way to get IncompleteDataException can be found in
addTypeOptions:While I understand that we might not want to make the mapping generation fail completely (so that users may test more easily), at least we should issue a warning. Or maybe even log an error.
Something to be considered: expressed concerned about issuing warnings, since in some enterprises they are considered blocking when putting applications in production.
I feel like one of the purposes of warnings is to inform users about potential error, and leave it to the user to decide if it's bad or not. So in this case, it would be exactly what we need. Now, if it's blocking for some users...
, , WDYT?