JS Unexpected behavior when serializing/deserializing
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- javascript
- Lĩnh vực
- backend-api-design
Hướng nghiên cứu
Tái hiện chuỗi setPkid/serializeBinary/deserializeBinary được hiển thị trong issue. Theo dõi setter của MyMessage và các điểm vào của quá trình tuần tự hóa/giải tuần tự hóa để xác định vị trí giá trị số trở thành chuỗi rỗng. Được xem là hoàn tất khi cách xử lý kiểu dữ liệu dự kiến có một fix được maintainer phê duyệt hoặc một quyết định được ghi lại.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Hello opening this issue because I've seen an unexpected behavior and want to discuss about it and see what's the best pattern
Given the following message:
message MyMessage {
String pkid = 1;
}
If I set a number field into pkid, I'm able to retrieve it correctly. Once I serialize and then deserialize the message, the value gets coerced as an empty string:
> protoConfig.setPkid(123);
> protoConfig.getPkid();
123
> MyMessage.deserializeBinary((protoConfig.serializeBinary())).getPkid()
""
I wasn't expecting the field to be transformed silently once the message is serialized. What I would expect from order of preference:
- Setting the field with
setPkidto crash (or a warning) because the type is not what was expected - Serialization crashing (or a warning) because the type is not expected
- Coercing the type using
toStringwhich would set it to '123'
I understand suggested behaviors may have performance implications but I'm not sure what's the reason of current behavior because this still forces the user to do type checks before setting fields in a protobuf message when using javascript? IMO silently changing the value of a field when serializing a message is dangerous and I would aim for correctness of data first.
- Ngôn ngữ chính
- JavaScript
- Star
- 471
- Fork
- 91
- Merge trung bình
- 1 ngày 12 giờ
- Pull request đã merge (30 ngày)
- 6
Chuẩn bị môi trường
Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của protocolbuffers/protobuf-javascript
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
protocolbuffers/protobuf-javascript#248 · 1 bình luận · 13 reaction ·
-
question
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
protocolbuffers/protobuf-javascript#222 · 9 bình luận ·
-
Why map.js sort keys?Đang mởenhancement port-fix triaged
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
protocolbuffers/protobuf-javascript#185 · 1 bình luận ·
-
enhancement port-fix triaged
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
protocolbuffers/protobuf-javascript#182 · 3 bình luận · 1 reaction ·
Tất cả issue của protocolbuffers/protobuf-javascript
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
openlibhums/janeway#5604 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] Generic OSC does not initialize OSC client on startup when "Listen for Feedback" is disabledĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
-
area/statement-execution TS conversion
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
scylladb/nodejs-rs-driver#584 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
新讀者走讀回報,照著一篇文章實際操作Đang mởdocumentation good first issue help wanted
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 92/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
Maintainer thường phản hồi trong vòng 3 ngày