Dynamically marshalling specific fields

[fcheslack]

Basically I am also looking for https://github.com/pquerna/ffjson/issues/150 (in some json library).

Wondering if you had ideas as to if/how you'd like to see support for it. I was thinking about adding an unexported function field to structs that need this support, and adding a conditional call to that function to the generated code.

type Selectable struct {
    A string
    B string
    easyjsonSelectField func(string) bool
}

s := Selectable{}
s.easyjsonSelectField = func(field string) bool {
    return true
}

This could be in addition to, or overriding omitempty. I don't like that this requires modifying the struct, but I couldn't easily think of a better way to provide support to dynamically manage such a thing from generated code.

Happy to hear if you have any opinions on this functionality in general, or implementation.

[vstarodub]

Hi! I think I'd need more info on the particular use case to come up with a solution or, at least, a suggestion. First of all, what's your business logic scenario for this? Is it something that comes up more or less often in general?

Do you need a shallow or a deep "selector", i.e. do you need to say that you don't want to marshal field 'A' of field 'B' of the struct? Do you need to marshal different set of fields for different elements of an array?

A shallow one is rather simple to implement and it does not require modifying the struct, but now I don't see how it will be useful.

For a deep selector, we are actually talking about querying a hierarchy of structs, which seems to be application specific and somewhat unrelated to serialization. It also looks like a thing like this might grow into something like LINQ (of which there are already multiple attempts to implement in golang).

This being said, it is quite possible to add an exported (it has to be) integer field that is tagged in a special way and that will act as a bitmask of fields to omit. The generator in turn will generate consts that can be used to actually mark the fields that will be omitted. But frankly I'd rather not do something like this without a reasonable use-case.

[fcheslack]

In my case, the primary use was this: I have a struct with a good number of fields, many of which are likely to be empty strings on a regular basis. Enough so that it seems cleaner, for possible human consumption, to have most of them be omitempty for JSON.

However, this struct may also be used in elasticsearch (or various other systems that speak JSON) which does updates with patch semantics, merging the update document into the existing document. This is desirable for various reasons, but requires the ability to explicitly set fields to empty values.

The way json encoding in the standard library (and the alternatives I'm aware of) works means I need to either have a struct field present in the JSON I marshal, or always leave it out when it's empty.

Instead, I'd like to, effectively, change the omitempty flag for each field at runtime, so I can leave fields out of an API response, while still being able to use patch semantics to update them.

A secondary aspect of it was a case where fields B and C are only relevant if field A has a particular value. Otherwise fields B and C will always been empty and consumers of the JSON could ignore them. So again, simply choosing contextually when I want a field to be omitempty.

I was assuming a shallow selector. Deeper selectors would be done by those nested struct's own Marshal functions (which is why I thought it requires the struct to carry this setting with it somehow).

[vstarodub]

So basically you need to distinguish empty and missing values during marshalling?

There are "optional" wrappers around primitive types in easyjson/opt for this use case. It requires slightly more code, but, on the other hand, these can be passed around as arguments.

[rvasily]

easyjson is simple instrument for json (de)serialization it's main purpose is achive performance by avoid runtime magic

if you want to cut some fields from result - you can use opt.* fields and control it by you app logic