Can EasyJSON support case insensitive match

[zhangruiskyline]

According to https://golang.org/pkg/encoding/json/#Unmarshal

Unmarshal matches incoming object keys to the keys used by Marshal (either the struct field name or its tag), preferring an exact match but also accepting a case-insensitive match

However, if we change to easyjson, it seems we need to be case sensitive, otherwise it fails to unmarshall, in our case, we want to make it can insensitive since our upstream may send both capital or lower case, can we do so in easy json?

[zhangruiskyline]

I think the problem is slightly different than #10, what I am looking at is in json tag, like

type User struct {
	DID string `json:"DID ,omitempty"`
	SID string `json:"SID,omitempty"`
}

so if the upstream sends out like "sid" instead of "SID", default JSON can parse correctly but easyjson can not , even use -snake_case flag dose not help. any idea how to make it more unique?

[zhangruiskyline]

re-surface this issue as it is quite significant blocking for us

[zhangruiskyline]

@vstarodub saw your comments in #10 , but my question seems to be different, do you know whether easyjson can easily support this?

Thanks
Rui

[rvasily]

stdlib works in runtime, so it cant try to look various name for fields.

easyjson now generates code, which parse only one name per field. camelCase, snake_case or from struct tags.

To support parsing from various name we need to add this feature to generator. PR are welcome

[zhangruiskyline]

So ideally we just need to convert each key to lower case in parser then in json structure tag we also put tag name in all lower case, then we should be good?

…

Sent from my iPhone

On Jun 26, 2019, at 2:18 AM, Vasily Romanov ***@***.***> wrote: stdlib works in runtime, so it cant try to look various name for fields. easyjson now generates code, which parse only one name per field. camelCase, snake_case or from struct tags. To support parsing from various name we need to add this feature to generator. PR are welcome — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[zhangruiskyline]

any idea when this can be prioritized? I would like to see it is quite high demand feature as lots of JSON situation we can not control counter partener behavior on case sensitive

Thanks
Rui

[shmel1k]

hm, case insensitive match is not a high priority feature, because it slows runtime too much. Too much allocations, unfortunately. So its better to use pre-defined json and not to have deal with insensitive case.

[zhangruiskyline]

I understand, but actually I think you can provide as option, and just convert all keys to lower case in your current match instead keep the original. maybe in this way, the overhead will be minimum?

[shmel1k]

It can be achieved with some patches in generator. But the memory overhead is very large)

[zhangruiskyline]

hmm, I am not seeing why memory overhead is large. in current parser you just get raw key, my suggestion is with this "case insensitive option", to a tolower(key) instead of directly use key.

anyway, if marshall/unmarshall speed can still beat general python, I am not that much worried about memory neither:)

[shmel1k]

I think youre always allowed to implement this feature)