FT.SEARCH & LIMIT - paging not working as expected in redisearch 1.4.0

[Davy Meybos]

I'm trying to query some paged results, but seeing strange behaviour.

Redisearch doesn't seem to handle the LIMIT command right. 

I've prepared a little example with 2 commands:

127.0.0.1:6379> FT.SEARCH idxCachedAuctionBatchItem "*" SORTBY EndDate ASC LIMIT 0 1

1) (integer) 1118

2) "CABI:161923"

3)  1) "AuctionBatchId"

    2) "161923"

...

127.0.0.1:6379> FT.SEARCH idxCachedAuctionBatchItem "*" SORTBY EndDate ASC LIMIT 1 1

1) (integer) 1118

2) "CABI:161923"

3)  1) "AuctionBatchId"

    2) "161923"

...

I expect the first command to return the first item only, the second command should return me the second item.

However each command returns the same item with the same ID.

I'm seeing the same behaviour when limiting per 10 (LIMIT 0 10, LIMIT 10 10, LIMIT 20 10...)

Am I understanding the LIMIT command wrong or is this a bug? I'm using version 1.4.0.

[Mark Nunberg]

Hi, I’ve tried to recreate the problem you’ve seen using both the current master as well as the 1.4.0 version, but the behavior is as expected each time. Can you provide a script which creates the data and reproduces the problem you’re seeing? I don’t agree this is the correct behavior.

#!/usr/bin/env python

from redis import StrictRedis

rr = StrictRedis()

# rr.flushdb()

rr.execute_command('ft.create', 'idx', 'schema', 'f1', 'text', 'f2', 'text', 'n1', 'numeric', 'sortable')

rr.execute_command('ft.add', 'idx', 'doc1', 1.0, 'fields', 'f1', 'first 1', 'f2', 'first 2', 'n1', 100)

rr.execute_command('ft.add', 'idx', 'doc2', 1.0, 'fields', 'f1', 'second 1', 'f2', 'second 2', 'n1', 200)

rr.execute_command('ft.add', 'idx', 'doc3', 1.0, 'fields', 'f1', 'third 1', 'f2', 'third 2', 'n1', 300)

print rr.execute_command('ft.search', 'idx', '*', 'sortby', 'n1', 'asc')

print rr.execute_command('ft.search', 'idx', '*', 'sortby', 'n1', 'asc', 'LIMIT', 0, 1)

print rr.execute_command('ft.search', 'idx', '*', 'sortby', 'n1', 'asc', 'LIMIT', 1, 1)

# output:

[3L, 'doc1', ['f1', 'first 1', 'f2', 'first 2', 'n1', '100'], 'doc2', ['f1', 'second 1', 'f2', 'second 2', 'n1', '200'], 'doc3', ['f1', 'third 1', 'f2', 'third 2', 'n1', '300']]

[3L, 'doc1', ['f1', 'first 1', 'f2', 'first 2', 'n1', '100']]

[3L, 'doc2', ['f1', 'second 1', 'f2', 'second 2', 'n1', '200']]

Note that you should verify you’re indeed using 1.4.0 or one of the newer versions. A while back, the parsing on the options was not as strict, and it may have been possible for options to just be ignored.

Mark Nunberg | Senior Software Engineer
Redis Labs - home of Redis

Email: ma...@redislabs.com

--
You received this message because you are subscribed to the Google Groups "redisearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redisearch+...@googlegroups.com.
To post to this group, send email to redis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/redisearch/61b81787-8ec2-470d-9942-192ac464f42e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Davy Meybos]

Hi Mark,

I can confirm the version we are using, it is actually 1.4.1. 

However after clearing our Redis database and populating it again (and recreating the indexes), we can see the paging is now working as expected.

We are also unable to recreate the problem at the moment, so it must have been a temporary issue with the indexes?

I'm very sorry I cannot provide you any better input for now.

[Meir Shpilraien]

Hey Davy,

If it will happened again please save the rdb and send it to us (if its possible), so we will be able to identify the problem.

Thanks.