10:53 p.m.
Hi,
After the upgrade to Search 5.5 (I think we skipped 5.4 on this app), I
have a weird behavior when I sort by id.
My id is a Long just indexed with @DocumentId:
@Id
@DocumentId
private Long id;
and my sort is defined like this:
fullTextQuery.setSort(new Sort(new SortField("id", SortField.Type.LONG,
true)));
Everything was reindexed.
It used to work before. Is this something expected?
--
Guillaume
10:59 p.m.
What is the exact behaviour you observe?
2015-09-23 22:53 GMT+02:00 Guillaume Smet <guillaume.smet(a)gmail.com>:
Hi,
After the upgrade to Search 5.5 (I think we skipped 5.4 on this app), I
have a weird behavior when I sort by id.
My id is a Long just indexed with @DocumentId:
@Id
@DocumentId
private Long id;
and my sort is defined like this:
fullTextQuery.setSort(new Sort(new SortField("id", SortField.Type.LONG,
true)));
Everything was reindexed.
It used to work before. Is this something expected?
--
Guillaume
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:05 p.m.
On Wed, Sep 23, 2015 at 10:59 PM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
What is the exact behaviour you observe?
Oh, yeah, forgot the most important :).
The results are completely unsorted. It should be sorted by id desc and I
have:
26687
26941
27034
27244
27235
28414
28327
11:08 p.m.
And the sort is different after each reindex.
On Wed, Sep 23, 2015 at 11:05 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
On Wed, Sep 23, 2015 at 10:59 PM, Gunnar Morling
<gunnar(a)hibernate.org>
wrote:
> What is the exact behaviour you observe?
>
Oh, yeah, forgot the most important :).
The results are completely unsorted. It should be sorted by id desc and I
have:
26687
26941
27034
27244
27235
28414
28327
11:18 p.m.
And if I sort by creationDate desc, the sort is OK. So I really think
there's something related to sorting on the id.
9:23 a.m.
Hi Guillaume,
The problem is that the document id is indexed as a STRING field by
default, which is not matched by your sort type LONG.
To make it work, your options are:
* Use SortField.Type.STRING to match the field's type
* Index your id field as numeric field (which I suppose makes more
sense for your use case) in which case you can use sort type LONG:
@Id
@NumericField
private Long id;
Of course you also could keep the default String field and add a
second, numeric field for sorting.
Either way, you should mark the field to sort on with @SortableField
which will cause that field to get indexed as doc value field, making
sorting much faster (see [1] and [2] for the details):
@Id
@NumericField
@SortableField
private Long id;
As a side-effect, this will expose the mismatch between field and sort
type through an exception upon query time. We assumed this would also
be the case with index uninverting (which is used without
@SortableField) but apparently that's not happening. There is an issue
[3] for improving that. HSEARCH should detect the mismatch itself
before letting Lucene run the query.
Cheers,
--Gunnar
[1] see http://staging.in.relation.to/2015/09/14/sorting-in-hibernate-search-55/
[2] http://hibernate.org/search/documentation/migrate/5.5/#sorting-options
[3] https://hibernate.atlassian.net/browse/HSEARCH-1951
2015-09-23 23:18 GMT+02:00 Guillaume Smet <guillaume.smet(a)gmail.com>:
And if I sort by creationDate desc, the sort is OK. So I really
think
there's something related to sorting on the id.
10:23 a.m.
Hi,
On Thu, Sep 24, 2015 at 09:23:20AM +0200, Gunnar Morling wrote:
Either way, you should mark the field to sort on with @SortableField
which will cause that field to get indexed as doc value field, making
sorting much faster (see [1] and [2] for the details):
@Id
@NumericField
@SortableField
private Long id;
To expand on this - you should not make any assumptions on the id field
or use it for indexing etc. We talked for a long time that we want to prevent
users to use the internal Search document id in queries and for sorting.
This would allow for optimizations of how for example the id is stored and
encoded.
If you need the id value for searches and/or sorting you should use additional
@Field annotations (using @Fields if you need more than one field). So in your
case you would for example add @Field(name="id_sort", ...). This is the most
future proof solution.
I don't think that just adding @NumericField will do, since it is just a companion
annotation to @Field.
--Hardy
10:47 a.m.
On Thu, Sep 24, 2015 at 10:28:14AM +0200, Gunnar Morling wrote:
> I don't think that just adding @NumericField will do, since
it is just a companion
> annotation to @Field.
It does work (at least as of 5.5 where we fixed some issues around
@NumericField); It applies to the implicit document id field in this
case.
Ok, still it makes modifications on the actual document id field, which
should be avoided for the mentioned reasons.
--Hardy
4:42 p.m.
Hi Hardy,
On Thu, Sep 24, 2015 at 10:47 AM, Hardy Ferentschik <hardy(a)hibernate.org>
wrote:
Ok, still it makes modifications on the actual document id field,
which
should be avoided for the mentioned reasons.
OK. I must admit that as it worked well before, we didn't think a lot about
using the @DocumentId field for sorting :).
I'll go clean up our applications!
Thanks.
3137
days inactive
3138
days old
9 comments
3 participants
participants (3)
-
Guillaume Smet -
Gunnar Morling -
Hardy Ferentschik