LIMIT for NUMERIC fields not working

[onexdrk]

steps to reproduce

1. prepare data

FT.CREATE testidx SCHEMA num NUMERIC name TEXT
FT.ADD testidx doc1 1 FIELDS num 140 name test
FT.ADD testidx doc2 1 FIELDS num 1400 name test
FT.ADD testidx doc3 1 FIELDS num 1405 name test

2. check with 2 records

 FT.SEARCH testidx "@num:[0 1000000]" LIMIT 0 2
return: doc1, doc3

 FT.SEARCH testidx "@num:[0 1000000]" LIMIT 1 2
return: doc2, doc3

 FT.SEARCH testidx "@num:[0 1000000]" LIMIT 2 2
return: doc2, doc3

3. check with 1 record

 FT.SEARCH testidx "@num:[0 1000000]" LIMIT 0 1
return: doc3

 FT.SEARCH testidx "@num:[0 1000000]" LIMIT 0 1
return: doc3

[dvirsky]

This is unrelated to numeric indexes, but a bug in paging when there are less results than 10. Will be fixed, thanks for catching this.

[dvirsky]

Okay, it's not actually what happens. The problem is that all documents have the same score so the compare function was unstable. I've changed it a bit and it seems to be working better.

If you want to sort by the numeric property, take a look at sortable properties and the SORTBY argument in the docs. http://redisearch.io/Sorting/

[onexdrk]

Got it, thanks. Is it already in master?

[dvirsky]

yes

[onexdrk]

Excuse me, but seems that i have another kind of problem. Imagine i want to organize paging functionality with page-size = 4

create an index and add five documents to it:

FT.CREATE indexName SCHEMA status TEXT

FT.ADD indexName doc1 1 FIELDS status open
FT.ADD indexName doc2 1 FIELDS status open
FT.ADD indexName doc3 1 FIELDS status open
FT.ADD indexName doc4 1 FIELDS status open
FT.ADD indexName doc5 1 FIELDS status open

Then i want to get first page with 4 elements in it:

FT.SEARCH indexName "@status:open" LIMIT 0 4
1) (integer) 5
2) "doc5"
3) 1) "status"
   2) "open"
4) "doc4"
5) 1) "status"
   2) "open"
6) "doc3"
7) 1) "status"
   2) "open"
8) "doc2"
9) 1) "status"
   2) "open"

response correct

Now i want go see last element:

FT.SEARCH indexName "@status:open" LIMIT 4 4
1) (integer) 5
2) "doc4"
3) 1) "status"
   2) "open"
4) "doc3"
5) 1) "status"
   2) "open"
6) "doc2"
7) 1) "status"
   2) "open"
8) "doc1"
9) 1) "status"
   2) "open"

Incorrect - must contains only doc1.

I think i can try fix it in backend and if it is last page - trim result and use just a tail, but it looks like a problem

[dvirsky]

The semantics are LIMIT {offset} {num} with a zero based index, so the 4th element should be accessed with LIMIT 3 1. However, this is in fact a bug, you are right.

[onexdrk]

Please, let me know if it will be fixed. May be open new issue about that?

[dvirsky]

Yes, I prefer another issue if you don't mind.

[onexdrk]

Yep, thanks, I'll create it