Skip to content

Guids serialized as strings even though the compatibility option is set to None #270

Open

Description

@moozzyk

If you use the following code to serialize a GUID value:

using (var ms = new MemoryStream())
{
    var packer = Packer.Create(ms, PackerCompatibilityOptions.None);
    packer.PackObject(Guid.NewGuid());
}

I will get the following result:

0xb0, 0x49, 0x92, 0xa0, 0x7d, 0xb2, 0x98, 0xfe, 0x4a, 0x97, 0xfe, 0xaf, 0xd9, 0xae, 0x91, 0x0e, 0x49, 0xb0, 0x2d, 0xd9, 0x75, 0xb6, 0x94, 0xa0, 0x5d, 0x4c, 0xb4, 0x4c, 0xe0, 0xd5, 0xad, 0x55, 0xeb, 0x67

so, the binary array representing the GUID has been serialized as a string of 15 characters (0xb0). My expectation was that because I used PackerCompatibilityOptions.None the byte array for GUID will be serialized as bin8 family (0xc4).

Looking at the code it seems that binX family is never considered when packing raw values. I would like to understand why this is the case and how raw values are typically unpacked if the language does not have strong type system (e.g. in JavaScript this GUID will be unpacked as string - is it then the user's responsibility to extract bytes?)

Activity

  1. yfakariya commented on Nov 5, 2017

    @yfakariya
    Member

    Thank you for feedback. There are two considerations about it.

    1. It is a bug that built-in Guid serializer does not honor PackerCompabilityOptions ( )
    2. Raw bytes should be unpacked as 'bytes which MAY be UTF-8 encoded string' because there were no binX famaliy in past. I think it is application's responsibility to specify the raw value is truly string or not.
  2. moozzyk commented on Nov 5, 2017

    @moozzyk
    Author
    1. So to recap, the built-in Guid serializer could/should use the binX family if the user passes PackerCompatibilityOptions.None.
    2. I came to the same conclusion. If the language does not have a strong type system or the client does not have a type that corresponds to the server type, the user/developer is the only one who knows how to interpret the data. If this is hard they might need to work around it, possibly, by using a different type.
  3. yfakariya commented on Nov 6, 2017

    @yfakariya
    Member

    I recognized that there are same bug for some other types. I will fixed it for next release (maybe RC)

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions