RFC: Add Formatters

[amorenoz]

Currently, the library does minimum data post-processing. This is a good approach, specially performance wise. However, it has the disadvantage of exposing ovsdb-specific formats (such as OvsSet and OvsMap) to the API clients.

I think it would be beneficial to be able to expose the data in more flexible ways. In order to keep backwards compatibility and access to the 'raw' data for clients that require it, I would like to propose adding another 'layer' of structs that can massage the output of OvsdbClient.
All Formatters should be able to ingest data coming from OvsdbClient such as Row and TransactResponse and return an arbitrary object with the post-processed data. Similarly, they should be able to consume data in arbitrary format and return structs consumed by OvsdbClient such as Mutation, Condition, or more generically, Operation. Unfortunately, since the returned types are different, it might not be possible to put all Formatters under an interface.

For instance, I can currently think of two possible Formatters:

NativeFormatter

This formatter could simply hide the ovs-specific fields such as OvsSet and OvsMap (not sure if it would be able to remove UUID since it would be difficult to distinguish from a normal string). For example:

struct NativeFormatter {}

// FormatRow simply removes OvsSet and OvsMap from the fields so they can safely be casted to native
// fields such as slices and maps.
func (f NativeFormatter) FormatRow(*libovsdb.Row) map[string] interface{}

// NewMutation creates a mutation from native types so you can create.
// example use:
// nf := NativeFormatter{}
// op := libovsdb.Operation {
// ...
// Mutations : nf.NewMutation("bridges", "insert", []string{"br0", "br1"})
// }
func (f NativeFormatter) NewMutation(column string, mutator string, value interface{}) []interface{}

DynamicFormatter

This Formatter could accept an additional pointer to a struct that would be populated based on dynamic type inference.
For example, we could define a ovs field tag that could be used by the formatter to determine how to populate the fields. For example:

type MyBridge struct {
    UUID            string      `ovs:"_uuid"`
    Name            string      `ovs:"name"`
    Controllers     [] string   `ovs:"controllers"`
}
struct DynamicFormatter {}

// FormatRow populates the object pointed by objPtr based on its 'ovn' tags
func (f NativeFormatter) FormatRow(row *libovsdb.Row, objPtr interface{}) error

I think having this functionality here in libovsdb could make it easier for clients to use it.
What do you think?

[amorenoz]

@hzhou8 @vtolstov This could serve as base for the automatically generated APIs that we're discussing in eBay/go-ovn#29

[vtolstov]

@hzhou8 i like approach with dynamic formatter, mostly naming are bad =)) i'm comment pr, thanks

[amorenoz]

@vtolstov I agree agree about the bad naming :)
Any suggestion?
s/Formatter/API/?
s/Dynamic/Typed/?