@miconda it happens on every delete. Our "table definitions" use Redis sets to simulate non-unique database indexes. For example if we have a key `entry:foobar` that is a hash and includes a key "test = blah" (so, `HMSET entry:foobar test blah`) and we use the "test" key as a non-unique index, then we'd have a set `index:test:blah` that includes `entry:foobar` as member (`SADD index:test:blah entry:foobar`). So when deleting `entry:foobar` we need to delete that from the `index:test:blah` set (`SREM ...`). This requires fetching the contents of the `entry:foobar` hash when deleting it. So with this commit, when `entry:foobar` is deleted directly by name, there will be no "manual keys" and so the HMGET is skipped and so the SREM fails.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/commit/bf2ecd4dec55d5009e0904392d083e1…
@rfuchs - apparently the patch was supposed to delete all entries, without a need to match on filters, according to PR #2140. Like the sql `delete from table` without `where` clause.
Now I understand that the sets keeping indexes are left. Does it happen for every type of `delete`, even when it has filters (i.e., `where` conditions)? Or only in the case of `delete all`?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/commit/bf2ecd4dec55d5009e0904392d083e1…
Hello @rdboisvert and @henningw
We bumped into this commit on our deployments because it was causing some issues. In particular it makes the Redis SETs that we use a pseudo-indexes being left over in the Redis DB after a delete operation. The reason is that even for deletes that can be done directly (no/empty "manual keys") the contents of the entry still need to be fetched because the contents are part of the key names used for pseudo-index SETs.
The patch we came up with is exactly the reversal of this commit, so obviously I need to ask about the intentions behind it, since I'm sure you had a good reason to do it :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/commit/bf2ecd4dec55d5009e0904392d083e1…