[hibernate-dev] [search] FieldBridge API change re-visited (HSEARCH-904)

[Hardy Ferentschik]

Turns out there might be an even easier solution.
Emmanuel suggested:

public interface FieldNameReportingBridge {
	Iterable<String> getGeneratedFieldNames(String baseFieldName);
}

In this approach we are actually passing the field name to get  
getGeneratedFieldNames
which means we don't have to make the bridges stateful. It also means that  
the current
bridge API stays untouched and hence the issues can be deferred to 4.x.

@Sanne, I know you had some additional reasons for changing the bridge  
API. What do you
think about this approach?

--Hardy


On Mon, 19 Sep 2011 23:19:17 +0200, Emmanuel Bernard  
<emmanuel at hibernate.org> wrote:

>>> What would option 2 gain? In particular what is the usefulness of the
>>> Iterable<String>?
>>> If it's to get the list of fields to be used by FieldSelector that's
>>> probably not correct as a given set operation might only affect a  
>>> subset
>>> of the potential fields.
>>
>> Sanne and I discussed this solution after you warned about making the
>> field bridge stateful. I guess the returned strings would have to be a
>> list of all potential field names a bridge adds. Of course this is not
>> intuitive at all.
>
> Right, an additional method (hosted on a diff interface probably) is  
> better for that.
>
>>
>> The easiest is to just pull out the field name parameter and move it to
>> initialize. Introducing something like IndexContext into the set method
>> (as discussed in Jira) could be an alternative, but to certain degree it
>> replaces LuceneOptions with something new.
>
> That's something I have not quite grasped, what would be the diff  
> between LuceneOptions and IndexContext (besides being a more generic  
> name and hence probably better.