HI Ben,
Thanks a lot for responding. Please see in line with tag ELMOHAN>
Thanks
Krishna Mohan
-----Original Message-----
From: Ben Pfaff [mailto:[email protected]]
Sent: Friday, April 01, 2016 9:26 AM
To: Elluru, Krishna Mohan <[email protected]>
Cc: [email protected]
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.
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
