Works perfectly with latest dockerimage but fails with RedisLabs ePack.
I am using FT.ADDHASH after a hmset.
Any hint on how to get a more descriptive error?
I'm sorry that it's not documented yet, but ADDHASH is not supported in enterprise cluster. Maybe there's a way around it? Let me know what you're trying to do.
@dvirsky simply index and retrieve by id.
Can I ask why isn't supported?
In the enterprise version, we distribute the document across many shards. To ensure that we control the partitioning automatically in a consistent way, we manipulate the document ids by adding {sharding_tags}. The partitioning scheme of the engine is independent of the one of redis.
So you sohuld only use FT.ADD ... REPLACE which is basically HMSET+indexing.
@dvirsky understood, so what about getting that document by id. isn't FT.SEARCH overkill for that?
yeah, it is. I can add something like FT.GET that just loads by doc id
yes! that would be awesome.
as a temporary workaround you can do this: run a purely negative query for a non existing term (that will return ALL documents), and limit it to the id(s) you want with INKEYS :). e.g. FT.SEARCH index "-asdfasdfasg" INKEYS 1 doc123. This will actually be pretty fast, but of course it's just an ugly hack.
@dvirsky I am unfamiliar with INKEYS and reading the docs sounds like the syntax is INKEYS 2 keyName1, keyName2 which differs a little bit from what yousuggested
it's simply INKEYS {num} {key} {key} .... no commas and no quotes needed.
Sure, so given a document with id "id-001" the query would be:
FT.SEARCH documents "-asdfasdfasg" INKEYS 1 id-100
gives me a syntax error
FT.SEARCH documents -asdfasdfasg INKEYS 1 id-100
doesn't return any result
?
Reading through the test suite (python) for INKEYS, maybe I am misreading the docs. Does INKEYS stand for only in this list of documents with these IDs ?
Ok I figured it out, it works :) -- The id I was indexing the document at was documents:<id> because of the previous implementation using hmaps. Removing documents: worked.
Last question: I also have a bulk get by id endpoint, I am basically passing the ids as INKEYS parameter and sorting it back once I get the results.
While this works I wanted to check if there is a better way for INKEY or the search call to respect the order of the values in INKEYS
@kilianc I'll make the FT.GET support multi keys and you'll get it exactly in the order you're querying. I'll do it today or tomorrow, now worries.
@kilianc i've implemented FT.GET and FT.MGET, they're pushed to master in the OSS module, after a bit more testing I'll release a new version of the enterprise module with both of them.
this is awesome, I am gonna look at the commit log and learn something today :). thanks
@kilianc I've released a new version of the enterprise module with this inside it. It also includes the fixes to the replication issues.
The build number is 9004
I'm closing this...
@dvirsky what's the correct way to update RediSearch without losing data? just swapping .so and restart?
There's an API to upgrade the enterprise cluster. Who's the SA working with
you, Guy?
On Wed, Oct 18, 2017, 8:23 PM Kilian Ciuffolo notifications@github.com
wrote:
@dvirsky https://github.com/dvirsky what's the correct way to update
RediSearch without losing data? just swapping .so and restart?—
You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub
https://github.com/RedisLabsModules/RediSearch/issues/185#issuecomment-337664462,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAetulhkTDgW4SHM-8azieS2VmpUsHlsks5stjPzgaJpZM4P2P-I
.
I talked to him before but I am not sure, I'll reach out via email and figure it out
The replication bug (fixed in the new version) might cause data loss, let me consult with Guy on the way to do it. You can email me directly or CC me to your emails to him, dvir at redis labs dot com. Thanks
I can wipe it out, it's a dev test cluster
Thanks, it will make things much easier. Next upgrade won't have this
problem.
On Thu, Oct 19, 2017 at 12:04 AM Kilian Ciuffolo notifications@github.com
wrote:
I can wipe it out, it's a dev test cluster
—
You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub
https://github.com/RedisLabsModules/RediSearch/issues/185#issuecomment-337727476,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAetuiFtQh0ulZih3rsR-Pezh80ThVjAks5stmfzgaJpZM4P2P-I
.