Provide adapter to store RESP3 maps in vector<pair<T, U>> - #434
Conversation
|
An automated preview of the documentation is available at https://434.redis.prtest3.cppalliance.org/libs/redis/doc/html/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-08-01 21:24:54 UTC |
c3a667f to
3df3448
Compare
| : result_(t) | ||
| { | ||
| if (result_) { | ||
| result_->value() = T{}; |
There was a problem hiding this comment.
I actually think I will undo this change as it will break user code. We should not erase data on behalf of the user and removing this line makes it possible to the user to append data to the container. The problem is that it will break user code and cause weird errors since not all users clear response objects before passing them to asyc_exec. It is something hard to change now.
There was a problem hiding this comment.
I agree - I think we've settled on not clearing data for the other adapters, and clearing for this one seems confusing.
| void on_node(Result& res, resp3::basic_node<String> const& nd, system::error_code& ec) | ||
| { | ||
| if (is_aggregate(nd.data_type)) { | ||
| auto const m = element_multiplicity(nd.data_type); |
There was a problem hiding this comment.
Shouldn't we require a multiplicity of exactly 2? What happens if the server sends us an array of 5 elements, for instance?
There was a problem hiding this comment.
I thought I wouldn't be so strict. By not requiring 2 the user would be able to read a RESP3 array into a vector<pair<U,V>>, which for odd sizes would let the last element undefined as you noticed. Perhaps you are correct and we should exit with expects_resp3_map, which might catch some usage errors earlier.
| if (node.data_type != resp3::type::null) { | ||
| op.emplace(T{}); | ||
| converter<T>::apply(op.value(), node, ec); | ||
| } |
There was a problem hiding this comment.
I think this is technically missing a else { op.reset(); }
|
This covers |
3df3448 to
d7fe631
Compare
Sure, thanks. It might not be trivial as I think there isn't a single concept that covers all e.g. map containers optimally. |
3 participants
No description provided.