feat(map): Add GetNextKey and GetValueAndDeleteKey #411
Conversation
@geyslan Hi, geyslan Support map apis in todo list, please review when you are free, thanks lot. |
chentao-kernel
force-pushed
the
dylane/key
branch
from
1592a92
to
8a5061f
Compare
|
@chentao-kernel I'm baking the next version. Please tell me if you'll have time to finish this so it can be part of it. 👍🏼 |
Yes, i can finish it |
chentao-kernel
force-pushed
the
dylane/key
branch
from
8a5061f
to
72f0885
Compare
@geyslan update it, please check again |
Add GetNextKey(), GetValueAndDeleteKey() and GetValueAndDeleteKeyFlags() to the map package. Signed-off-by: Tao Chen <chen.dylane@gmail.com> Co-authored-by: Geyslan Gregório <geyslan@gmail.com>
|
@chentao-kernel I raised this chentao-kernel#3. |
Add GetNextKey(), GetValueAndDeleteKey() and GetValueAndDeleteKeyFlags() to the map package. Signed-off-by: Tao Chen <chen.dylane@gmail.com> Co-authored-by: Geyslan Gregório <geyslan@gmail.com>
chentao-kernel
force-pushed
the
dylane/key
branch
from
72f0885
to
03d86e3
Compare
Dylane/key
@geyslan hi, geyslan, thank you for your help, it was mergered. |
|
@chentao-kernel, I was rethinking this API and realised that the initial TODO comment led to an erroneous GetNextKey signature as it is not performant (always allocating a buffer to store the fetched key value). This idea was brought up because in the current codebase we have some methods that work as helpers, already instantiating the values and doing the dirty work for the consumer. However, continuing with this approach is limiting the user to a sub-optimized API. So I bring the idea of from this new API we bring 1:1 wrappers and through them we create new helpers (with sugar and without performance guarantee). I'll close this PR and soon send another one with this idea on top of your work. In any case, it's a thing that should be addressed in the rest of the codebase, both for new and existing APIs. |
excellent，l saw your pr. |
Add GetNextKey() and GetValueAndDeleteKey() for map and map-low.