[ovs-dev] [PATCH 1/1] ovsdb-idl: Retain column values of deleted rows until change-track is cleared.

[Ryan Moats]

Ben Pfaff <blp at ovn.org> wrote on 04/11/2016 06:08:13 PM:

> From: Ben Pfaff <blp at ovn.org>
> To: Ryan Moats/Omaha/IBM at IBMUS
> Cc: "Ansari, Shad" <shad.ansari at hpe.com>, "dev at openvswitch.org"
> <dev at openvswitch.org>
> Date: 04/11/2016 06:08 PM
> Subject: Re: [ovs-dev] [PATCH 1/1] ovsdb-idl: Retain column values
> of deleted rows until change-track is cleared.
>
> On Fri, Apr 01, 2016 at 10:15:42AM -0600, Ryan Moats wrote:
> > It looks like the calls to SBREC_*_EACH_TRACKED only show you the
> > incremental changes since tracking was turned on.
>
> I thought that was the point!
>
> Can you explain your vision for what you expect to get out of change
> tracking?  I don't understand it yet.
>
> > Now, that may in fact be how it was intended to work, but if so, then
> > I question it's usefulness.  In ovn-controller, I can foresee code
> > paths that differ only in that one uses SBREC_*_FOR_EACH_TRACKED and
> > the other uses SBREC_*_FOR_EACH, and that's going to be a bit ugly.
>

Coming from a bit more of a traditional DB background, I expected
change tracking to be something applied *at the server* and carried
atomically in the row data. The result is that when I ask for tracked
changes, I'm getting the ordered list of changes from either the
"beginning of time" or from the last change number I provide
[which I hadn't found and sort of confused me]. This was the reason
for the code to track and reset sequence numbers.

Since that's obviously not the case (and I think I finally have my
head wrapped around that fact), v13 is going to need a major
refactoring in terms of code structure and how the patches are
arranged. I've been kicking the tires on what that might look like
while you were on vacation, but I'm now buckling down today and
working through all the details.

Ryan