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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev