On Thu 2013-01-03 18:19, Ales Justin wrote:
> I think anything handled by not-Lucene is wrong.
> >>>
> >>> I'm afraid Lucene won't do it, so we have no option. It's definitely
> >>> not designed to do this: even a custom Collector can't return more
> >>> results than Documents in its segment,
I think anything handled by not-Lucene is wrong.
>>>
>>> I'm afraid Lucene won't do it, so we have no option. It's definitely
>>> not designed to do this: even a custom Collector can't return more
>>> results than Documents in its segment, as all representations work by
>>> using int as relat
On 3 January 2013 18:11, Emmanuel Bernard wrote:
> On Thu 2013-01-03 17:59, Ales Justin wrote:
>> >> I think anything handled by not-Lucene is wrong.
>> >
>> > I'm afraid Lucene won't do it, so we have no option. It's definitely
>> > not designed to do this: even a custom Collector can't return mo
On Thu 2013-01-03 17:59, Ales Justin wrote:
> >> I think anything handled by not-Lucene is wrong.
> >
> > I'm afraid Lucene won't do it, so we have no option. It's definitely
> > not designed to do this: even a custom Collector can't return more
> > results than Documents in its segment, as all re
>> I think anything handled by not-Lucene is wrong.
>
> I'm afraid Lucene won't do it, so we have no option. It's definitely
> not designed to do this: even a custom Collector can't return more
> results than Documents in its segment, as all representations work by
> using int as relative ids.
Ev
On 3 January 2013 15:29, Ales Justin wrote:
> I think anything handled by not-Lucene is wrong.
I'm afraid Lucene won't do it, so we have no option. It's definitely
not designed to do this: even a custom Collector can't return more
results than Documents in its segment, as all representations work
I think anything handled by not-Lucene is wrong.
As Lucene, in this case, is the only engine that can properly address all query
details - order, filtering, ...
So, imo, the only way to do this is by having multiple documents, one per
cartesian product element.
How to go from there, is a big TOD
I don't think it's as simple as you imply. If we go that route the
engine atop Hibernate Search would need to know that a given field is
multivaluable (it could be a serialized List otherwise) and look into
each entry in the Object[] to "cartesianize it".
It's doable but it seems that it would be
Hi Marko,
this is expected by our typical users, as you only have multiple field
values on tokenized fields, and you won't project these; occasionally
someone uses the _addFieldToDocument_ multiple times to give the
illusion of merging multiple strings to be tokenized in the same
stream, or occasio
Hi,
we've found the following problem regarding projection queries when
dealing with documents containing multiple fields with the same name.
Let's say we add field "foo" with two different values to the same document:
luceneOptions.addFieldToDocument("foo", "aaa", document);
luceneOptions.addF
10 matches
Mail list logo
