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

[Emmanuel Bernard]

On 19 sept. 2011, at 23:14, Hardy Ferentschik wrote:

> On Sep 19, 2011, at 15:00, 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.