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? Elluru, Krishna Mohan wrote: > On the similar note, > > 1. if the column is an index, and a weak reference with mutable:false, > the similar behavior can be expected? > 2. if the column is an index, and a weak reference with mutable:false, > and the table is ROOT table, what behavior should be expected, if the > referenced row is deleted? Ben Pfaff wrote: > The solution I suggested above would also eliminate these issues. Elluru, Krishna Mohan wrote: > then, mutable : false on a strong reference would be a problem right? > I meant, mutable:false can't be used at all with references? What will > be the usecase for a strong reference to have mutable:false, I can't > delete the referenced row without clearing all strong references to > it, and I can't modify the column as it would violate the mutable > property. I feel this to be discussed more. I guess that this would mean that both rows (the one with the strong reference and the one that it references) would have to be deleted together. I don't know whether that is useful, but it is not a hole in the constraint system in the same way as with a weak reference, so it is not obvious to me that anything needs to change. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
