Closed andig closed 1 year ago
@andig hey, i think you want:
data := map[string]any{
"loadpoints": []any{
map[string]any{
"id": 1,
},
},
}
[]map[string]
is not a type used by gojq, it wants []any
Could you point me to where in the code that happens? Should bot be too difficult, to assign type to any in this case, but its really ugly to do this for the source any.
I guess the panic you see if from here https://github.com/itchyny/gojq/blob/bf454af8ae4b652543220a5a67456109224518de/type.go#L27 or https://github.com/itchyny/gojq/blob/bf454af8ae4b652543220a5a67456109224518de/encoder.go#L72 i think @itchyny probably have to answer about assigning/converting but i guess for implementation simplicity and to model the allowed types as close to JSON as possible (array elements can have mixed types)
Thank you for the pointers. These two would be simple to fix, maybe like this:
func TypeOf(v any) string {
switch v.(type) {
case nil:
return "null"
case bool:
return "boolean"
case int, float64, *big.Int:
return "number"
case string:
return "string"
default:
switch typ := reflect.TypeOf(v); typ.Kind() {
case reflect.Slice:
return "array"
case reflect.Map:
if typ.Key().Kind() == reflect.String {
return "object"
}
fallthrough
default:
panic(fmt.Sprintf("invalid type: %[1]T (%[1]v)", v))
}
}
}
However, there is a larger bunch of type checks around like these:
case int, float64, *big.Int:
i, _ := toInt(x)
switch v := v.(type) {
case nil:
return nil
case []any:
return index(v, i)
case string:
return indexString(v, i)
default:
return &expectedArrayError{v}
Changing every single occurrence would be quite a refactor. It seems it would be easier to apply this transformation on the source than in gojq after all. That said- that is basically what passing it through json does apparently.
This limitation is mentioned in the README.md.
The type should be
[]any
for an array andmap[string]any
for a map (just like decoded to anany
using theencoding/json
package). You can't use[]int
ormap[string]string
, for example.
This limitation not only simplifies the implementation, but improves the performance (reflection is slow), and also makes the library extention easy (consider if WithFunction
users have to handle any type of slice and map).
This is a design decision of this library. Closing as wontfix.
Thank you for the feedback and sorry for not noticing this in the README! Happy with the wontfix :)
I'm trying to use jq directly against Go structures instead of unmarshaled JSON. This test case fails:
Running the same query on the unmarshaled json works fine. Please advise if this is unexpected usage of the library?