.. 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
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
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
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
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
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
13 matches
Mail list logo
