Dots in field names for generated Go code

[praseodym]

The ECS guidelines mention that “The document structure should be nested JSON objects.”. However, some ECS fields, such as cloud.instance.id are defined as dotted fields under a group.

While this is handled just fine in the Elasticsearch template using a nested properties object, the generated Go code contains the dotted field name just like any regular field name. I don’t think a document using a nested JSON object for such a field will properly deserialize using the generated code (aside from the Go code not having any json: keys in the struct field tags at all).

[andrewkroh]

There's a plan in the works to refactor all the generators used in this repo. It should be possible to modify the generator to produce code that is compatible out-of-the-box with the encoding/json package.

I added the existing code because I found myself implementing these types in multiple places and keeping them in sync with the spec was hard. I figured I'd come back to add a means of marshaling to JSON, but haven't found time. For my use case I have custom marshaler that reads the ecs tags.

[sporkmonger]

Also none of the generated Go code uses omitempty in tags, which I suspect will cause issues for most real-world marshaling usage.

[willie]

I came here to basically say the same thing @sporkmonger. Not having json or omitempty (for non required fields) really makes the generated Go code difficult to use in real world code where you want ecs compatible JSON. I tried to add omitempty in gocodegen.go, but the loops and tricks to find that field after the YAML is marshaled is extraordinarily obscure (libbeat is weird place, once you manage to find the right version). I don't mean to come off angry, I just really wanted to fix it and submit a PR for it, but the what is using what to determine the fields stopped me cold. I see the plan for the new generators and that's interesting. I subscribe to that PR. In the meantime, if you have suggestions for how to find the status of required in the YAML so I can alter the generator, I'd be happy to fix it.

[djptek]

The GoLang code generator and dependencies have now been removed, see:

#1567
#1585

Closing