5:39 a.m.
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
8 a.m.
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
4:14 p.m.
On Sep 19, 2011, at 15:00, 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.
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.
--hardy
4:19 p.m.
On 19 sept. 2011, at 23:14, Hardy Ferentschik wrote:
On Sep 19, 2011, at 15:00, 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.
9:49 a.m.
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.
4843
days inactive
4844
days old
4 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Hardy Ferentschik