-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type hinting in serialization depends on field ordering #34
Comments
Yeah, I'm on board for this, just requires a minor version bump due to breaking change. I've been aware of this limitation for a while. |
Ok, I'm happy to send a PR if you wish. Thanks a lot for your review of the others :) |
Yep @cpg314, your contributions are much appreciated. :) I added you as a contributor so you can stack your PRs. |
Fixed by #37 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When struct fields are not declared in the same order as in the database, type hints will be passed to the wrong fields.
This affects only structs with fields requiring a type hint (decimal, bytes...) and results in an error from the server.
Detailed description
The
Row::serialize_row
method signature isIt is called in
client.rs
as follows:The
Row
derive macro implementsserialize_row
by iterating over fields, and callingtypes[idx]
to get the type hint for each fieldThere is however no guarantee that the fields order will match between the ones in the struct declaration and in
first_block
(returned by the server).Example
This test passes, but fails if
a
andb
are switched in thestruct
declaration:Indeed,
b
now gets the type hint meant fora
.Solution
The solution is pretty simple but requires a change to the
Row
trait:In
client.rs
,column_types
is originally anIndexMap
in aBlock
. Rather than passing it as a slice, one should pass theIndexMap
, allowing to safely retrieve field type hints by name.This would change the signature of
serialize_row
toThe text was updated successfully, but these errors were encountered: