If the deletes are within a single transaction, they'll be reported as part of a single update, and the IDL will present them all together as a unit.
If the deletes happen in different transactions then they'll be reported sequentially, in the same order they were applied to the database. If you're actually seeing different behavior then I'd like a reproduction case; that shouldn't happen. On Wed, Jun 10, 2015 at 09:41:51AM -0700, Saurabh Shrivastava (सौरभ श्रीवास्तव) wrote: > Thanks Ben. I have seen that when a transaction is deleting rowA which > points to rowB which points to rowC, and if all the references to rowB and > rowC are gone, the updates generated can be in any order ie rowC delete can > be received before deletes for rowA or rowB. Should this be expected for > "deletes"? > > > -- > Saurabh (सौरभ) > > On Wed, Jun 10, 2015 at 8:15 AM, Ben Pfaff <b...@nicira.com> wrote: > > > On Wed, Jun 10, 2015 at 07:55:20AM -0700, Ben Pfaff wrote: > > > On Tue, Jun 09, 2015 at 11:16:34PM -0700, Saurabh Shrivastava (सौरभ > > श्रीवास्तव) wrote: > > > > When OVSDB server sends updates to an OVSDB client, the IDL changes > > > > idl_seqno. When idl_seqno changes, the client can rebrowse the IDL and > > look > > > > for changes. > > > > > > > > Does OVSDB server guarantee that the updates always maintain > > referential > > > > integrity for row creation and row updates i.e. if the client browses > > the > > > > IDL it should never run into a situation where rowA in tableA points > > to a > > > > non-existent rowB in tableB because the update for rowA has arrived but > > > > update for rowB is still in flight. > > > > > > Yes. > > > > I sent out a patch to document this: > > http://openvswitch.org/pipermail/dev/2015-June/056200.html > > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
