In the context of Hibernate Search metadata, here are the proposed non-ambiguous definitions:
* Field relative name: the name given with the {{@Field}} annotation (or similar, like {{@Spatial}})
* Field path name : the name absolute path , i.e. the relative 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}}.
{code}
private static void processMetadataRecursivelyForProjections(TypeMetadata typeMetadata, String[] fields, Object[] result, Document document, ConversionContext contextualBridge)
{
//process base fields
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 ); // <==== BUG HERE
try {
populateResult(
fieldName,
fieldMetadata.getFieldBridge(),
fieldMetadata.getStore(),
result,
document,
contextualBridge,
matchingPosition
);
}
finally {
contextualBridge.popProperty();
}
}
}
}
{code}
That's why I'd like to make a global pass on attributes and variables to make their names consistent. |
|