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
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
I have done some tests and you are correct. The token / secret seems
legit though. I tried to renew them but got a HTTP 500 from GitHub. I
have open a support ticket.
Emmanuel
On Wed 2013-01-02 23:33, Sanne Grinovero wrote:
> Hi all,
> I noticed that "hibernate_dev" doesn't seem to be tweeting ab
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
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
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
Hi,
Just want to let you know, I took some time of today ( my last new year holiday
day ) and tried to migrate hibernate-shards to use hibernate orm 4.x
I pushed things to my fork(hibernate4 branch)
https://github.com/stliu/hibernate-shards/tree/hibernate4
have finished the following things:
1
>> 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 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
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
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 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,
.. and final is scheduled for next week!
All details here:
http://in.relation.to/Bloggers/HibernateSearchCR1JBossModulesSpatialImprovementsNRTBoosting
Regards,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/ma
13 matches
Mail list logo
