On Wed, Mar 23, 2016 at 07:46:57AM -0600, Ryan Moats wrote: > Ben Pfaff <b...@ovn.org> wrote on 03/22/2016 05:05:22 PM: > > One thing I'm trying to understand in this series is the reliance on > > seqnos that come from the IDL. I'm surprised that they're used so > > much. I would have guessed that the typical use of change tracking > > would be something like this: > > > > For each row that changed, > > If it's new, create a new object to track it; > > otherwise, it's modified or deleted, so look up an existing > > object based on the row's uuid and update or delete it as > > appropriate > > > > But instead logic seems to look at these seqnos a lot. What is the > > principle that you're following? > > I chose to use IDLs instead of the row's uuid because the insert seqno > acts as pretty much as a uuid and I was sure that I could trust them > even when a row is deleted. Unfortunately, that led to a bunch of > "magic" that I really didn't like. I'll go back and double check to > make sure that a row uuid's remain usable after a row is deleted - if > they do, then I'm all in favor of using uuids as it should simplify > a bunch of things...
I thought that the change-tracking code retained deleted rows for inspection until the tracking cache was flushed. If it doesn't, then maybe that should be changed. At the very least, I would think that the uuid of the deleted row would be available. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
