Add tuple get/set for object properties (Issue #19)

[obloquy]

Currently tuples only support scalar properties. This patch adds basic support for objects (map[string]interface{}). Basic unit tests are included. This relates to #19.

We need this in a project to avoid considerable work in flattening existing request objects.

Since objects are mutable they are not allowed as tuple keys, this is prevented with a small change in tupledescriptor.UmarshalJSON. The other main limitation is that if an object is mutated in an action it will need to be set again with tuple.SetObject() in order to re-run the change listeners. The 'object' contents can be accessed via type assertions which is better than not having anything. Alternatively something like https://github.com/mitchellh/mapstructure can be used to get a real structure, or you can marshal->json->unmarshal->structure.

The resource file can be set up with the following to make it work with a REST trigger:

 {
    "settings": {
      "method": "POST",
      "path": "/test/n2"
    },
    "actions": [
      {
        "id": "simple_rule",
        "input": {
          "tupletype": "n2",
          "values": "=$.content"
        }
      }
    ]
 }

And the tuple descriptor:

"tds": [
  {
    "name": "n2",
    "properties": [
      {
        "name": "name",
        "pk-index": 0,
        "type": "string"
      },
      {
        "name": "thing",
        "type": "object"
      }
    ],
  }
]

POST content:

{
    "name": "Bob",
    "thing": {"foo":{"bar":"baz"}}
}

[jpark800]

• Even though this works with a JSON formatted object, an object in non-JSON syntax will likely to cause a failure. It could perhaps be supported by changing the type name from "object" to "json". This will indicate that an arbitrary json format data is expected as input.

• How is the proposal different compared to using a string type value given that unmarshalling a json string is doable in a condition or an action function? It would be nice to add a concrete test case that shows a problem being solved.

[obloquy]

I agree it only works for JSON but not because of anything in the PR. The rule action code has unmarshaling hardcoded in it. https://github.com/project-flogo/rules/blob/master/ruleaction/action.go#L170-L171
I also agree there are other ways to achieve the same thing, I just consider the approach in this PR the cleaner way of doing it because it handles objects the same ways as Flogo-core. It seems odd to have to change the structure of a request as it goes from core to rules, and to have to reformat rule results for the same reason. In particular having JSON encoded inside a JSON string seems particularly dirty. But that's fine, it is what it is, I've already worked around it.

[ykalidin]

Using the above code we could see that the Type object is accepting pk-index, when the below tds is given as json in the Flogo model.

"tds": [
          {
            "name": "n1",
            "properties": [
              {
                "name": "thing",
                "type": "object",
                "pk-index": 0
              }
            ]
          }
        ]

Attached the flogo.json and functions.go required to run the example.
object.zip

When we use the same tds in API model the error(Error [Property [name] is a mutable object and cannot be defined as a key for type [n1]]) is thrown and its working fine.

[obloquy]

Closing this. It isn’t needed and I don’t have time to improve it.