Encoding map[string]interface

[shreenibk]

Hi,

Can we use jingo encoder on map[string]interface data type ?
Looking encoder for something like below code snippet.

Using the map_support branch

Tried this code on https://play.golang.org/

panic: reflect: Key of non-map type main.AddrTable

goroutine 1 [running]:
reflect.(*rtype).Key(0x4fcae0, 0xc00001a080, 0xc000068e38)
/usr/local/go-faketime/src/reflect/type.go:960 +0xce
github.com/bet365/jingo.NewMapEncoderWithConfig(0x4fcae0, 0xc000012210, 0xc000012200, 0xc000012210)
/tmp/gopath116140931/pkg/mod/github.com/bet365/[email protected]/mapencoder.go:53 +0xc5
github.com/bet365/jingo.NewMapEncoder(0x4fcae0, 0xc000012210, 0x4fcae0)
/tmp/gopath116140931/pkg/mod/github.com/bet365/[email protected]/mapencoder.go:32 +0x3a
main.main()
/tmp/sandbox039335348/prog.go:21 +0x22e

Thanks

• Shrinivas

// go get github.com/bet365/jingo@map_support
// Updated the go.mod

package main

import (
"fmt"

"github.com/bet365/jingo"

)

type AddrTable struct {
First string json:"first"
Last string json:"last"
Id uint32 json:"id"
Pin uint64 json:"pin"
}

// Create an encoder, letting it know which type of struct we're going to be encoding.
// You only do this once per type!
func main() {
addr := map[string]interface{}{"first": "Shrinivas", "last": "Kulkarni", "id": 1234, "pin": 112233445566}

var enc = jingo.NewMapEncoder(AddrTable{})

//fmt.Println(reflect.TypeOf(addr))
fmt.Println(addr)

// pull a buffer from the pool and pass it along with the struct to Marshal
buf := jingo.NewBufferFromPool()
enc.Marshal(&addr, buf)

//fmt.Println(reflect.TypeOf(buf), reflect.TypeOf(buf.String()))

// fatal error: found pointer to free object
fmt.Println(buf.String())

// return the buffer to the pool now we're done
buf.ReturnToPool()

}
-- go.mod --
module encode

require github.com/bet365/jingo v1.0.3-0.20210217031143-c45208b1e242 // indirect

[kungfusheep]

Hi

Jingo works by knowing the shape of the data it is encoding ahead of time.

interface{} removes its ability to know this so the only way to support it would be to use reflection, which removes the speed benefits of jingo.

If you want the performance benefits possible with this package it might be worth trying to structure your data in a way that is sympathetic to this constraint.

Thanks - and apologies for the length of time it took to respond.