Make TextualFromNative output deterministic

[lebaptiste]

TextualFromNative output is not deterministic due to the underlying map type used for the data struct.
Ideally the method should be deterministic similarly to what the json.Marshal already does by sorting the map keys.

Current behaviour:

        codec, err := goavro.NewCodec(`
	{
		"type": "record",
		"name": "Schema",
		"fields" : [
		  {"name": "first", "type": "string"},
		  {"name": "second", "type": "string"}
		]
	}`)
	if err != nil {
		fmt.Println(err)
	}

	val := map[string]interface{}{"first":"foo", "second":"bar"}
	for i:=0; i<20;i++ {
		b, _ := codec.TextualFromNative(nil, val)
		fmt.Println(string(b))
	}

Result:

{"first":"foo","second":"bar"}
{"second":"bar","first":"foo"}
{"first":"foo","second":"bar"}
{"second":"bar","first":"foo"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"second":"bar","first":"foo"}
{"first":"foo","second":"bar"}
{"second":"bar","first":"foo"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}
{"first":"foo","second":"bar"}

[galion96]

Hello, I am also experiencing this issue.
Is there any plan to make a fix for this?

[xmcqueen]

checking

[ckarmann]

Another way to make it deterministic would be to keep the order of the fields in the records in the schema. It would be consistent with what produce Avro library for Java and also with avro-tools.

In general the question of being deterministic is not just to have a consistent JSON representation: the result of going Binary -> Native -> Textual -> Native -> Binary should get you back where you started. And this should be the case regardless of which platform created the first binary. A lot of Avro data around here has been created in Hadoop by Java processes so I think this library should be consistent with it.

For the same reason, maps should try to keep the ordering all along. This means it can not simply use Go's map implementation. An equivalent of Java's LinkedHashMap should be used instead.