chore: hset family replies and trim #3748
Conversation
dranikpg
force-pushed
the
hset-fam-trim
branch
5 times, most recently
from
1879deb
to
f628bca
Compare
Signed-off-by: Vladislav <vladislav.oleshko@gmail.com> Signed-off-by: Vladislav Oleshko <vlad@dragonflydb.io>
dranikpg
force-pushed
the
hset-fam-trim
branch
from
f628bca
to
7b9c55d
Compare
| DCHECK(dynamic_cast<RedisReplyBuilder*>(cntx->reply_builder())); | ||
| } | ||
|
|
||
| template <typename T> void Send(OpResult<T> res) { |
There was a problem hiding this comment.
I remember you added a similar approach on Sets (although it was not the exact same logic). What I don't remember if you added this on another family. If you did check if there is simlar logic and extract it into a base class which we can the reuse among families with this exact same pattern of replies (if they exist in the first place).
| } else { | ||
| cntx->SendError(result.status()); | ||
| } | ||
| HSetReplies{cntx}.Send(cntx->transaction->ScheduleSingleHopT(cb)); |
There was a problem hiding this comment.
also here if key not found should return 0 and not key not found
maybe also add a unit test for this and hdel
There was a problem hiding this comment.
oh I see that this logic for hlen is in the OpLen implementation, this is confusing, I would add this logic to OpDel as well instead of the change in line 781
| cntx->SendError(result.status()); | ||
| } | ||
| if (result.status() == OpStatus::KEY_NOTFOUND) | ||
| result = OpResult<uint32_t>(0); |
There was a problem hiding this comment.
can you add unit test for this please
No description provided.