IntegerValue should capture the size of the integer

[velvia]

The MessagePack serialized format knows the size of an Int, whether it's 8, 16, 32, or 64 bits. However the current IntegerValue class loses this information, and it forces the user to pick the right method, getShort, getInt, etc. It would be nice for IntegerValue to capture the original size of the integer when deserializing, and the same thing when it serializes.

[andreas]

This is causing some problems for me as well (similar to https://github.com/tinkerpop/rexster/issues/295). What are the complications of adding BYTE, SHORT and LONG to ValueType so the proper type can be read back?

[oza]

I apologize for the delay. I'll do this in a few days. Thanks for reporting.

[oza]

I've implemented this feature.Please see test code to know the how this conversion works.
oza@d5d942c#L8L131

@andreas, is this enough for your use case? If you have quetions, let me know.

[andreas]

@oza, that's perfect. Thank you very much for the swift action!

I would like to suggest mentioning in the readme, that integers are packed in as few bytes as possible without regard to their type, i.e. unpack(pack(1L)) != 1L but rather unpack(pack(1L)) == (byte) 1. It makes sense, but can be a gotcha.

[oza]

@andreas, ah, I agree with you. I'll add documentation how msgpack-java packs/unpacks its value.

[oza]

@andreas, before going forward. I'd like to crarify the use case. When would you like to use this feature?

[andreas]

Msgpack is used as serialization format for the Rexpro protocol. In Rexpro, you can send a script to be executed on the server along with a set of bindings for variables, e.g. "run x + y with the bindings { x: 1, y: 2 }". Currently, all integers/floats passed in the bindings are deserialized on the server as long/doubles, since there's no way to know the original size. This creates some weird behaviour, e.g. x == 1 with bindings { x: 1 } returns false, since 1 is an int and x is a long.

Explaining this to you, I now see that this patch may not solve the problem, since the original size of x is still lost. It seems like Rexpro needs unpack(pack(1)) == 1. Maybe this problem should not be solved by Msgpack, but in Rexpro by passing along the type information (something like { x: ["int", 1] }). Alternatively msgpack-java could offer a mode that respects the type of its arguments. What do you think?

[oza]

@andreas I apologize for taking time to answer.

Currently, all integers/floats passed in the bindings are deserialized on the server as long/doubles,since there's no way to know the original size.

I have a question to use a serialized type as the original type of the object. For instance, when the long value 0 is serialized, it can be deserialized as byte, short, int, and long value 0. There are no relation between serialized-side type and deserialized side type. IMHO, type embedding, therefore, should be done in application layer - for example, by sending an object { x: ["int", 1] } directly as you mentioned.

[xerial]

In the message pack specification, integer value just conveys 63-bit signed integer:
https://github.com/msgpack/msgpack/blob/master/spec.md#types-limitation

So to support checking the actual message format type, it would be better to add a method (e.g., Value.getMessageFormatType) or let MessageUnpacker return the last read MessageFormat type. I think the latter is appropriate since Value is a separate notion from MessageFormat.