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 <az...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
