Skip to content
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

Encoding: Longs default value of 0 is not being set on the wire #639

Closed
robin-anil opened this issue Jan 12, 2017 · 14 comments
Closed

Encoding: Longs default value of 0 is not being set on the wire #639

robin-anil opened this issue Jan 12, 2017 · 14 comments

Comments

@robin-anil
Copy link
Contributor

protobuf.js version: master

Is this intended? If the field is set java proto2 library does not ignore defaults and sets it on the byte stream

@robin-anil robin-anil changed the title Longs default value of 0 is not being set on the wire Encoding: Longs default value of 0 is not being set on the wire Jan 12, 2017
@robin-anil
Copy link
Contributor Author

In general anything set (either on the object or present in the json from which it is parsed) should be on the wire.

@dcodeIO
Copy link
Member

dcodeIO commented Jan 12, 2017

I always assumed that such default values would ideally be excluded on the wire for efficiency, at least that's what I'd expect. Do you know if this is an official implementation detail or if it just happens that the Java lib does it this way?

@robin-anil
Copy link
Contributor Author

robin-anil commented Jan 12, 2017

I guess it is official implementation detail based on both C++ and Java libraries (~8 years of exp now). I don't know about the other languages.

@robin-anil
Copy link
Contributor Author

With proto3 I presume you can make the argument that default values should be excluded. But I have definitely been used to the behavior of value being set in the proto2 world.

@robin-anil
Copy link
Contributor Author

Could you help get a release out with a fix for this issue. This is the last remaining issue with migrating our code-base.

@dcodeIO
Copy link
Member

dcodeIO commented Jan 14, 2017

Sorry, have been busy fixing jsPerf today. On top of that, a fix for this would break a lot of stuff, as the entire default values on prototypes model is involved. Just using hasOwnProperty to solve this would yield terrible performance afaik (need to revalidate that).

see - but this could be broken if defined checks are optimized away.

@dcodeIO
Copy link
Member

dcodeIO commented Jan 16, 2017

I've now tested an implementation that uses Object.keys to determine which values are present. Unfortunately, that's 33% slower than what we have now (bench drops from 513k to 342k ops/s).

@dcodeIO
Copy link
Member

dcodeIO commented Jan 16, 2017

Now testing an implementation using hasOwnProperty. This does in fact seem to drop by just a bit with all the default value checks removed. Investigating.

@dcodeIO
Copy link
Member

dcodeIO commented Jan 16, 2017

As a side-product, generated toObject implementations are super fast now using hasOwnPropery instead of Object.keys.

@robin-anil
Copy link
Contributor Author

Works great! Now I need a new release and I push our new converted code base to QA!

@dcodeIO
Copy link
Member

dcodeIO commented Jan 17, 2017

Released on npm. Feel free to reopen if there are any issues!

@dcodeIO dcodeIO closed this as completed Jan 17, 2017
@robin-anil
Copy link
Contributor Author

robin-anil commented Jan 19, 2017

@dcodeIO I am seeing more related issues. nulled/undefined string fields are being sent as empty strings. across the wire

Version: 6.5.0

@dcodeIO
Copy link
Member

dcodeIO commented Jan 19, 2017

Reference: https://github.com/dcodeIO/protobuf.js/blob/master/src/encoder.js#L88

Might be the case for required fields, yeah. Should throw on .verify though. Can you provide an example?

@robin-anil
Copy link
Contributor Author

These are not required fields, lets continue conversation here #652

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants