[ovs-dev] [mointor2 4/9] lib: add diff and apply diff APIs for ovsdb_datum

[Ben Pfaff]

On Wed, Oct 21, 2015 at 09:45:26PM -0700, Andy Zhou wrote:
> When an OVSDB column change its value, it is more efficient to only
> send what has changed, rather than sending the entire new copy.
> This is analogous to software programmer send patches rather than
> the entire source file.
> 
> For columns store a single element, the "diff" datum is the same
> as the "new" datum.
> 
> For columns that store set or map, it is only necessary to send the
> information about the elements changed (including addition or removal).
> The "diff" for those types are all elements that are changed.
> 
> Those APIs are mainly used for implementing a new OVSDB server
> "udpate2" JSON-RPC notification, which encodes modifications
> of a column with the contents of those "diff"s. Later patch implements
> the "udpate2" notification.

s/udpate2/update2/, in two places above.

> Signed-off-by: Andy Zhou <azhou at nicira.com>

...

> +/* Generate a difference ovsdb_dataum between 'old' and 'new'.
> + * 'new' can be regenerated by applying the difference to the 'old'.
> + *
> + * The diff operation is reversible. Given 'old',
> + * 'new' can be recreated by applying diff to 'old'.
>
> + * Thus
> + *     Let  d = 'old' diff 'new'
> + *     then 'new' = 'old' diff d

That's a nice property.  Good thinking, I'm sure I would have missed
that at first.

> + * The generated datum is always safe; the orders of keys are maintained
> + * since they are added in order.
> + *
> + * Caller is responsible for freeing the memory returned.   */

It seems that allocating the ovsdb_datum itself is unusual within the
ovsdb-data.c interface.  It seems that it would be more consistent with
the other functions if the caller had to supply it.

Same for ovsdb_datum_apply_diff().

In the test, it would be a little better, I think, if the new diff test
printed out the difference, so that one could visually see that it made
sense and we would know if anything happened to change.

Thanks,

Ben.