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

Nested protobufs of mismatching types do not serialize correctly #180

Closed
ghost opened this issue Aug 22, 2014 · 1 comment
Closed

Nested protobufs of mismatching types do not serialize correctly #180

ghost opened this issue Aug 22, 2014 · 1 comment

Comments

@ghost
Copy link

ghost commented Aug 22, 2014

Definition:

message Child {
    optional uint32 foo = 1;
}

message FakeChild {
    optional uint32 foo = 1;
}

message Parent {
    optional Child child = 1;
}

Code:

var foo = new Parent({child: new FakeChild({foo: 1})});

Confusingly, this results in: Error: Illegal value for Message.Field .Child.foo of type uint32: object (not an integer). I believe the correct behavior should be serializing FakeChild as an instance of Child, as this will mean that imported types will serialize correctly as child messages.

@dcodeIO
Copy link
Member

dcodeIO commented Aug 22, 2014

I assume this behavior originates from: https://github.com/dcodeIO/ProtoBuf.js/blob/master/src/ProtoBuf/Builder/Message.js#L43

When given a single argument, the constructor has to distinguish if it's either just referencing the first field or if it is an object containing fields (it allows both multiple arguments in field declaration order and a single object). The argument could be another message (which is an object), just referencing the first field in declaration order.

As a result, the else condition tries to set the first field's value (this is Child.foo) to the argument, which is an instance of FakeChild.

I'll think about a solution, but unfortunately, I don't see a good one atm except dropping field declaration order entirely.

Edit: Well, there seems to be a bit more to that as an instance of Child works. Still puzzled. An instance of child works as there is a check in place here which circumvents the issue. This happens only if the statements returns false (not a proper instance). A possible solution could be placed right below the instanceof check statement.

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

1 participant