Feature suggestion: FT.SEARCH - optional "which fields to return" modifier about redisearch HOT 5 CLOSED

Yeah, it's been in the TODO for ages, and it should really be trivial to implement :) Also generating snippets on the fly would be nice.

from redisearch.

(hint: PRs would be welcome ;) )

from redisearch.

BTW - not really a workaround, but you can of course retrieve the IDs and then do HMGET on them, the documents are stored simply as plain redis hashes.

from redisearch.

@mnunberg you can take this one, it's pretty straightforward.

1. The API should look like RETURN {num} {field} {field}.... Having the number allows us to have field names that are reserved words, similar to INKEYS, INFIELDS, etc.

2. This should be reflected in the RSSearchRequest struct.

3. Field names must be copied to the request, because the query will be execute on a separate thread after the original caller's auto memory has finished freeing them

4. RETURN 0 is valid and equivalent to NOCONTENT. I wouldn't enforce a limit on the number of fields, but make sure that it's not overflowing argc of course.

5. Non indexed fields that are not in the schema are allowed - the schema only refers to indexing, it is perfectly okay to add documents with fields outside the schema. Just use the fields for the RM_HashGet call.

6. fields should be case sensitive in this context. There are places they aren't but I want to move to a fully case sensitive mode of operation, we can start here :)

7. When you're done, don't forget:
   a. a python test.
   b. document this in Commands.md
   b. please add this feature to the python and java clients.

Thanks!

from redisearch.

Fixed in current master, will be included in next release.

from redisearch.