Post Filter & Sort Descriptors with query.limit enabled

[Aj]

For best performance and scalability, avoid using this; instead create another view whose keys include the thing you want to sort by. But it’s not always possible to do this; sometimes you really need to specify a key range one way and then sort a different way. That’s what 'sortDescriptors' feature is for

Sometimes you really need to specify a key range one way and then sort a different way & paginate the query results. How can I achieve this? Applying sortDescriptor + limit to query doesn't gives me expected result. 

My situation is paginating a list of 'Issues' 

- Apply optional filter criteria (filter by "Email" or "Status")

- sort by ("title" or "email" or "creation date" or "modified date")

So, my emit line looks like this, 

emit(@[project,archived,map,status],@[title,email,creationDate,modifiedDate]); //first 3 keys are very important filters

Is it not possible to apply sort descriptor and limit ? (please make my life easy :D)

postFilter Question

I observed that applying "limit + postFilter" gives gives limit+1 results. Shall I file a issue? 

Following returns me 51 results (without limit, 354 results).

query.postFilter = [NSPredicate predicateWithFormat:@"key[3] == %@",@"created"];

query.limit = 50;

[query run:nil]

Thanks

[Jens Alfke]

On Aug 25, 2015, at 7:42 AM, Aj <ajith...@icloud.com> wrote:

Sometimes you really need to specify a key range one way and then sort a different way & paginate the query results. How can I achieve this? Applying sortDescriptor + limit to query doesn't gives me expected result. 

Good point — the offset/limit are being applied before the in-memory sorting, which gives the wrong results. Could you file an issue on this, please?

However, the query isn’t going to be very efficient, since it’ll be generating the entire result set, sorting it, and then throwing away the results outside the current page. It may be better for you to keep the entire result set in memory and just display the relevant portions.

I observed that applying "limit + postFilter" gives gives limit+1 results. Shall I file a issue? 

Weird! Must be an off-by-one error in there somewhere. Yes, definitely a bug, so file an issue please.

—Jens

[Aj]

However, the query isn’t going to be very efficient, since it’ll be generating the entire result set, sorting it, and then throwing away the results outside the current page. It may be better for you to keep the entire result set in memory and just display the relevant portions.

 Results count could be over 5000 (or more in future). Without 'sortDescriptors', I may have to write following views. 

emit(@[project,archived,lastModified],@[email,status])
emit(@[project,archived,title],@[email,status])
emit(@[project,archived,responsible],@[email,status])
emit(@[project,archived,dueDate],@[email,status])

emit(@[project,archived,map,lastModified],@[email,status])
emit(@[project,archived,map,title],@[email,status])
emit(@[project,archived,map,responsible],@[email,status])
emit(@[project,archived,map,dueDate],@[email,status])

I'll still have to use 'postFilter' on the "value" objects. Will the query going to be inefficient even in this case? Not using "postFilter" is going to result in lot of views (see here https://friendpaste.com/2aNqHn0Hg8mwLHgTsDuRuC )

emit(@[project,email,status],@1)

emit(@[project,status,email],@1)

And, I was wondering if there is any way to avoid writing two views for above case? I only swapped index of objects inside key array. 

[Jens Alfke]

> On Aug 26, 2015, at 3:34 AM, Aj <ajith...@icloud.com> wrote:
>
> Results count could be over 5000 (or more in future).

5000 doesn’t sound too bad. Each query row is only going to use a few hundred bytes, depending on the key and value sizes. (If you want to save room, emit nil as the value.)

—Jens