diff mbox

[ovs-dev] Add change tracking documentation

Message ID 1461281327-7627-1-git-send-email-rmoats@us.ibm.com
State Changes Requested
Headers show

Commit Message

Ryan Moats April 21, 2016, 11:28 p.m. UTC 
From: RYAN D. MOATS <rmoats@us.ibm.com>

Change tracking is a bit different from what someone with
"classic" database experience might expect, so let's add
the knowledged gained from the experience of making change
tracking work for incremental processing.

Signed-off-by: RYAN D. MOATS <rmoats@us.ibm.com>
---
 lib/ovsdb-idl.h |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

Comments

Ansari, Shad April 22, 2016, 4:38 p.m. UTC | #1 
> +/* Change tracking.  In OVSDB, change tracking is applied at each

> +client in

> + * the IDL layer.  This means that when a client makes a request to

> +track

> + * changes on a particular table, they are essentially requesting

> + * information about the incremental changes to that table from the

> +point in

> + * time that the request is made.  Once the client clears tracked

> +changes,

> + * that information will no longer be available.  


Suggestion: I would leave it at that. The implication you are deriving may not apply to all usages.
Ryan Moats April 22, 2016, 9:23 p.m. UTC | #2 
"Ansari, Shad" <shad.ansari@hpe.com> wrote on 04/22/2016 11:38:17 AM:

> From: "Ansari, Shad" <shad.ansari@hpe.com>
> To: Ryan Moats/Omaha/IBM@IBMUS, "dev@openvswitch.org"
<dev@openvswitch.org>
> Date: 04/22/2016 11:39 AM
> Subject: RE: [ovs-dev] [PATCH] Add change tracking documentation
>
>
> > +/* Change tracking.  In OVSDB, change tracking is applied at each
> > +client in
> > + * the IDL layer.  This means that when a client makes a request to
> > +track
> > + * changes on a particular table, they are essentially requesting
> > + * information about the incremental changes to that table from the
> > +point in
> > + * time that the request is made.  Once the client clears tracked
> > +changes,
> > + * that information will no longer be available.
>
> Suggestion: I would leave it at that. The implication you are
> deriving may not apply to all usages.

I don't quite agree with just leaving it there.  The fact is that
one *can't* replay past changes after they are cleared and so if
a client requires replaying the untracked past, it faces the difficult
choice of either trying to remember the changes itself (which I believe
translates into a memory leak), or having two independent code paths.

Now, I'm willing to move the statement beyond into a separate paragraph
and wordsmith it to the above, but I'm not comfortable with just
leaving it be at the above.

Ryan
diff mbox

Patch

diff --git a/lib/ovsdb-idl.h b/lib/ovsdb-idl.h
index bad2dc6..538602c 100644
--- a/lib/ovsdb-idl.h
+++ b/lib/ovsdb-idl.h
@@ -113,7 +113,15 @@  void ovsdb_idl_add_table(struct ovsdb_idl *,
 void ovsdb_idl_omit(struct ovsdb_idl *, const struct ovsdb_idl_column *);
 void ovsdb_idl_omit_alert(struct ovsdb_idl *, const struct ovsdb_idl_column *);
 
-/* Change tracking. */
+/* Change tracking.  In OVSDB, change tracking is applied at each client in
+ * the IDL layer.  This means that when a client makes a request to track
+ * changes on a particular table, they are essentially requesting 
+ * information about the incremental changes to that table from the point in
+ * time that the request is made.  Once the client clears tracked changes,
+ * that information will no longer be available.  The implication of this
+ * is that it is not a simple matter for code to "replay" changes from the
+ * past.  Rather, code should be structured with a path for processing the
+ * full table as well as a path that processes incremental changes.  */
 enum ovsdb_idl_change {
     OVSDB_IDL_CHANGE_INSERT,
     OVSDB_IDL_CHANGE_MODIFY,