Register Go int as long in type resolver #423
Conversation
| @@ -550,3 550,94 @@ func TestEncoder_UnionInterfaceNotInSchema(t *testing.T) { | |||
|
|
|||
| assert.Error(t, err) | |||
| } | |||
|
|
|||
| func TestEncoder_UnionResolver(t *testing.T) { | |||
There was a problem hiding this comment.
I didn't find any tests testing this behavior so I added it, specifically the test case Go int as Avro long tests the line added in this PR. It's written in a different style than the other tests in this repo, if you prefer I can split it up into separate tests.
| @@ -26,6 26,7 @@ func NewTypeResolver() *TypeResolver { | |||
| r.Register(string(Int), int16(0)) | |||
| r.Register(string(Int), int32(0)) | |||
| r.Register(string(Int), int(0)) | |||
| r.Register(string(Long), int(0)) | |||
There was a problem hiding this comment.
Should this only be for 64 but systems?
There was a problem hiding this comment.
I don't think so, let me explain.
In case of encoding, you can encode int32 and int64 as long, both should be fine. And this is enabled now because TypeResolver.Name(int) will return long as a possible type for encoding int.
Now, in the case of decoding it's only safe to decode long into int64. This is till the case though, because in the next line we register int64 as long, so TypeResolver.Type("long") will still return int64, as it was before.
I noticed that
inttypes are not resolved aslongin unions, so I registered it in the type resolver.Follow-up to #422.
Related to #421.