| In the context of Hibernate Search metadata, here are the proposed non-ambiguous definitions:
- Field name: the name given with the @Field annotation (or similar, like @Spatial)
- Field path: the name, prefixed with any relevant @IndexedEmbedded.prefix
- Property name: the name of the source property for a field in the annotated javabean, which may not be the same as the field name (especially when the user explicitly gives @Field.name)
In the current code, we seem to indistinctively use "fieldName" about everywhere, making it unclear whether a string is a simple relative field name, a full absolute field path, or a javabean property name. This has already resulted in confusions such as in the snippet below, where we push a field path where a property name is expected. Even if no custom field name is used, this will result in very strange paths: for example with a property "a.b.c", we'll get something like "a.a.b.a.b.c" in exceptions thrown by the ConversionContext.
private static void processMetadataRecursivelyForProjections(TypeMetadata typeMetadata, String[] fields, Object[] result, Document document, ConversionContext contextualBridge)
{
for ( PropertyMetadata propertyMetadata : typeMetadata.getAllPropertyMetadata() ) {
for ( DocumentFieldMetadata fieldMetadata : propertyMetadata.getFieldMetadataSet() ) {
final String fieldName = fieldMetadata.getName();
int matchingPosition = getFieldPosition( fields, fieldName );
if ( matchingPosition != -1 && result[matchingPosition] == NOT_SET ) {
contextualBridge.pushProperty( fieldName ); try {
populateResult(
fieldName,
fieldMetadata.getFieldBridge(),
fieldMetadata.getStore(),
result,
document,
contextualBridge,
matchingPosition
);
}
finally {
contextualBridge.popProperty();
}
}
}
}
That's why I'd like to make a global pass on attributes and variables to make their names consistent. |