Turns out there might be an even easier solution.
Emmanuel suggested:
public interface FieldNameReportingBridge {
Iterable getGeneratedFieldNames(String baseFieldName);
}
In this approach we are actually passing the field name to get
getGeneratedFieldNames
which means we don't have to m
On 19 sept. 2011, at 23:14, Hardy Ferentschik wrote:
> On Sep 19, 2011, at 15:00, Emmanuel Bernard wrote:
>
>> What would option 2 gain? In particular what is the usefulness of the
>> Iterable?
>> If it's to get the list of fields to be used by FieldSelector that's
>> probably not correct a
On Sep 19, 2011, at 15:00, Emmanuel Bernard wrote:
> What would option 2 gain? In particular what is the usefulness of the
> Iterable?
> 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 p
What would option 2 gain? In particular what is the usefulness of the
Iterable?
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 w
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
