Re: [hibernate-dev] [search] FieldBridge API change re-visited (HSEARCH-904)
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(a)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.