So with RediSearch 1.x we’ve always manually created our index and manually added documents to it. What was indexed wasn’t a hash table, but simply bits of information stored in the redis key value (simple string value). This would be like storing a person’s name from the person key who has visited certain cities. I’m sure I’m not explaining this correctly, but if I understand correctly Redis 2.0 doesn’t allow this.
This also meant our index didn’t have any relationship to one specific key. With 2.0 it tries to create a hash with the detail provided. So if we wanted to do the same, we’d have to structure our data like:
cities:los_angeles:visited:frank (or something). Point being, we can’t just create an index and populate it manually. Am I understanding that correctly? I know I’m saying this poorly, but we’re looking to functionally create indexes based on related keys (similar to a join) and store that index as something other than the keys that it’s indexing.
Your understanding of how RediSearch 2.0 seems sound but I’m having some trouble understanding your specific challenge. RediSearch 2.0 stores an index under the name you give it when you call FT.CREATE and monitors all changes to keys that match the patterns provided in that same call to FT.CREATE. Calls to FT.ADD just create Hashes where before it just added to the index.
Is the problem that you don’t want the hashes? Or you want lots of indices but don’t want to namespace your Hashes? I think it’s the latter and if so, I think you just have to namespace your Hashes.
If that doesn’t work, and depending on your requirements, you might be able to maintain indices manually using Sets. This depends on if you are using the full text search capabilities or not. If you are, this won’t work.
I think I actually figured out a solution. We basically want to show data within related keys. So I THINK the right solution is to simply write a new set of hashes. With my example, it would be something like:
cities:los_angeles:visited:bob (with whatever important info/hashkeys we wanted to search for)
cities:los_angeles:visited:amy
which would be what we wanted to index from different sets of keys such as:
city:los_angeles:whatever
people:bob
And then create the index with a prefix cities:lost_angeles:visited
So during the course of normal business, we’d CREATE the hash keys that are indexed (and update them as necessary), but the index wouldn’t have to be rebuilt or anything, it would just work as is (not really calling “add” to the index, you’re just adding/removing/updating the hash keys as needed.