> That makes no sense. If the bytes were the same, how would deserializing
> them be able to produce unequal messages?
Yes, I guess if we can rely on the canonical ordering of the fields,
that should be enough.
> If possible, I would recommend designing your application such that it only
> requ
On Tue, Sep 29, 2009 at 12:41, alopecoid wrote:
>
>> Given that the serialized bytes have to be able to *deserialize* back
>> to the original messages, surely if those original messages aren't
>> equal, the serialized forms would have to be different too - assuming
>> we're talking about the same
On Tue, Sep 29, 2009 at 12:41 PM, alopecoid wrote:
> But, as in my example, that doesn't seem to be the case (necessarily).
> Again, for example, let's say you have two messages, both of the same
> type. The proto defines two optional fields, both of type variable
> int64.
>
> Say message A poopu
On Tue, Sep 29, 2009 at 12:22 PM, alopecoid wrote:
>
> Hi,
>
> Can serialized messages be used reliably as keys?
>
> In other words, is it guaranteed that...
>
> - Two equal messages will always generate equal byte sequences?
> (Are fields always written in the same
> Given that the serialized bytes have to be able to *deserialize* back
> to the original messages, surely if those original messages aren't
> equal, the serialized forms would have to be different too - assuming
> we're talking about the same message type
But, as in my example, that doesn't seem
On Sep 29, 8:22 pm, alopecoid wrote:
> Can serialized messages be used reliably as keys?
>
> In other words, is it guaranteed that...
>
> - Two equal messages will always generate equal byte sequences?
> (Are fields always written in the same order?)
>
> - Two uneq
Hi,
Can serialized messages be used reliably as keys?
In other words, is it guaranteed that...
- Two equal messages will always generate equal byte sequences?
(Are fields always written in the same order?)
- Two unequal messages will always generate unequal byte sequences?
(Are tag
