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

[Elluru, Krishna Mohan]

HI Ben,
	Thanks a lot for responding. Please see in line with tag ELMOHAN>

Thanks
Krishna Mohan

-----Original Message-----
From: Ben Pfaff [mailto:blp at ovn.org] 
Sent: Friday, April 01, 2016 9:26 AM
To: Elluru, Krishna Mohan <elluru.kri.mohan at hpe.com>
Cc: discuss at openvswitch.org
Subject: Re: [ovs-discuss] Clarification regarding Mutable attribute in the column

On Fri, Apr 01, 2016 at 03:46:50AM +0000, 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?

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?

ELMOHAN> 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.

	On the contrary, yes, if it can be fixed would allow us to define schema correctly.

> 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?

The solution I suggested above would also eliminate these issues.
ELMOHAN> 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.