JS Unexpected behavior when serializing/deserializing
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 25/100
- Tipo de issue
- Bug
- Clareza
- Precisa de esclarecimento
- Status de atividade
- Estagnada
- Stack de tecnologia
- javascript
- Domínio
- backend-api-design
Direção de pesquisa
Reproduza a sequência setPkid/serializeBinary/deserializeBinary mostrada na issue. Rastreie o setter de MyMessage e os pontos de entrada de serialização/desserialização para identificar onde o valor numérico se torna uma string vazia. O trabalho estará concluído quando o tratamento de tipos esperado tiver um fix aprovado por um maintainer ou uma decisão documentada.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- JavaScript
- Estrelas
- 471
- Forks
- 91
- Merge médio
- 1d 12h
- PRs com merge (30d)
- 6
Preparar o ambiente
Ainda não verificamos os arquivos de configuração deste projeto. Comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de protocolbuffers/protobuf-javascript
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 25/100
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 30/100
protocolbuffers/protobuf-javascript#248 · 1 comentário · 13 reações ·
-
question
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 45/100
protocolbuffers/protobuf-javascript#222 · 9 comentários ·
-
Why map.js sort keys?Abertaenhancement port-fix triaged
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 35/100
protocolbuffers/protobuf-javascript#185 · 1 comentário ·
-
enhancement port-fix triaged
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 35/100
protocolbuffers/protobuf-javascript#182 · 3 comentários · 1 reação ·
Todas as issues de protocolbuffers/protobuf-javascript
Issues semelhantes
-
refactor
Dificuldade 2/5 Meio dia Facilidade para iniciantes 84/100
Mantenedores costumam responder em até 5 dias
-
translation
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
ciderapp/translations#87 · 1 comentário ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 67/100
Mantenedores costumam responder em até 1 dia
-
component: split-view platform: windows
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
zen-browser/desktop#15616 · 1 reação ·
Mantenedores costumam responder em até 1 dia