allow storing map[string]interface{}

[kjk]

And all other operations on that type.

[kjk]

There are some challenges/design decisions related to handling maps. Some of them.

1. Go doesn't allow comparing maps to each other. We need comparison (to e.g. find the value cached in session).

Solution: Store etc. require a pointer to map. This is similar to not supporting a struct and requiring a pointer to a struct, but it does feel weird for maps.

Similarly, a Load will most likely require **map which looks even weirder but while we could accept *map and make it work, we would lose identity of the value i.e., unlike other values, what we get from Load would be (from the point of Go), a different value, which would break all functionality based on being able to uniquely identify a value (like GetMetadataFor etc.).

2. What should be the collection/id for maps when the user doesn't specify id explicitly?

For structs, we use the name of the struct. We could use "maps" for the name of the collection. Or require the user to always provide it. TODO: check what Java does

Alternatively, we could make both Load and Store etc. accept just map. That makes for a more intuitive API but would break everything that relies on knowing the identity of the object (e.g. GetMetadataFor).

3. Should map returned by Load contain @metadata? What happens when we set/modify @metadata? Are the values filtered on send? TODO: check what Java does.

4. What should GetFullTypeName return?

5. Should we set "ID" key when storing? TODO: check what Java does.

Places in code that need to be scrutinized: go<->json conversions (entityToJSON, treeToValue etc.), tryGetIDFromInstance().