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

[Emmanuel Bernard]

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.


On 19 sept. 2011, at 12:39, Hardy Ferentschik wrote:

> Hi,
> 
> sorry to bring this issue up again, but when starting the refactoring for  
> this issue (taking the approach
> to make the bridge stateful) I noticed a problem. We thought that we could  
> introduce
> 
> FieldBridge#initalize(String fieldName, LuceneOptions options)
> 
> while removing the same parameters from the set method. The assumption was  
> that LuceneOptions are constant
> for a given field. It turns out this is not the case. Due to dynamic  
> boosting the boost factor can actually
> change on each call to set.
> 
> The question is what to do now?
> 
> 1. Just have FieldBridge#initalize(String fieldName) and keep the  
> LuceneOptions in set?
> 2. Keep the stateless interface, but change set to
>    Iterable<String> set(String name, Object value, Document document,  
> LuceneOptions luceneOptions);
> 3. Try to find a way which does not require the changing LuceneOptions.  
> See also comment on the Jira issue.
> 
> Thoughts?
> 
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev