[ovs-discuss] Clarification regarding Mutable attribute in the column

Ben Pfaff blp at ovn.org
Fri Apr 1 15:17:44 UTC 2016


On Fri, Apr 01, 2016 at 04:55:59AM +0000, Elluru, Krishna Mohan wrote:
> Elluru, Krishna Mohan wrote:
> > I am observing one of the behavior with ovsdb(2.5), for which I would 
> > like to seek clarity. As per the RFC 7047, if a column on table X with 
> > attribute is set to mutable:false, the value can't be changed after 
> > creation and on attempt the constraint violation error would be thrown 
> > to the caller. However, if the column is a weak reference and pointing 
> > to UUID of another table (say y) with mutable:false on the column, and 
> > on row deletion in Y table, what is the intended action on table X's 
> > row?. Currently my observation shows that the corresponding row in 
> > Table X is being deleted. Is this behavior is a bug or intended 
> > behavior?
> 
> Ben Pfaff wrote:
> > This is a hole in the constraint system that had not previously been 
> > brought to my attention.
> > 
> > I'd prefer to solve it by forbidding weak references from immutable 
> > columns.  Does this suit you?
> 
> Elluru, Krishna Mohan wrote:
> > I have two versions here.  I am actually happy with this behavior, in 
> > real use case. For Ex: I have a port table referenced from nexthop 
> > table with uuid and mutable property set to false. Due to above 
> > behavior, when I delete the port table row, without flushing the 
> > entries in nexthop table, port row was allowed to be deleted(ofcourse 
> > after clearing other strong references) and the nextop rows were 
> > garbage collected. This is a nice behavior according to me, since the 
> > row itself is being deleted(I meant garbage collected), I didn't feel 
> > the need to raise it earlier, till someone quoted it as a bug to me. 
> > Open to views and suggestions.
> 
> My goal, when I included immutable columns into OVSDB, was to enable
> clients to treat them as invariants.  This simplifies some of the
> logic of the clients.  That's why, for example, the "name" column in
> the Open_vSwitch schema's Interface table is immutable; it simplified
> logic in some places in ovs-vswitchd and I didn't see any significant
> downsides.
> 
> I am not sure of other reasons why columns would be invariant.  In
> your example above for example, why is it valuable for the column
> (that actually changes due to deletion of the row to which it refers)
> to be invariant?  Does it simplify something?  That is, why not make
> the column mutable?
> 
> ELMOHAN> the advantage is more from the automatic cleanup by the DB,
> ELMOHAN> than the code doing it. If I delete a port row, without
> ELMOHAN> worrying(scanning) 10k(just an example) references from
> ELMOHAN> nexthop table to it, and DB taking care of flushing those
> ELMOHAN> automatically (with internal logic ., may be gc). However,
> ELMOHAN> with mutable property set to true, my work still be there of
> ELMOHAN> clearing all 10k records + port record in same commit txn, I
> ELMOHAN> feel that is large txn (sorry if I am
> ELMOHAN> exaggerating). Regarding the constraint violation, I viewed
> ELMOHAN> it as we didn't modified the column actually, when the txn
> ELMOHAN> violated the constraint, the corresponding row has been
> ELMOHAN> deleted and the DB is brought stable due to that. I could be
> ELMOHAN> wrong here, for me it looks like a nice feature to have.

I don't understand yet.  I understand this much: when you delete a port
row, you'd like the references to it to disappear.  That works just as
well whether the referring column is mutable or immutable.  So why is it
important for it to be immutable?



More information about the discuss mailing list