Report incomplete metadata issues during Elasticsearch mapping generation

Description

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?

Environment

None

Activity

Show:
Guillaume Smet
November 9, 2016, 1:30 PM

Could you give us an example of a case where this error would be considered normal?

Yoann Rodière
November 9, 2016, 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.

Assignee

Yoann Rodière

Reporter

Yoann Rodière

Labels

None

Suitable for new contributors

None

Feedback Requested

None

Components

Fix versions

Affects versions

Priority

Minor
Configure