HI Ben,
Please see inline.
Please correct my understanding, if any.
Thanks
Krishna Mohan.
-----Original Message-----
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Friday, April 01, 2016 10:07 AM
To: Elluru, Krishna Mohan <elluru.kri.mo...@hpe.com>
Cc: discuss@openvswitch.org
Subject: Re: [ovs-discuss] Clarification regarding Mutable attribute in the
column
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, than the
code doing it. If I delete a port row, without worrying(scanning) 10k(just an
example) references from nexthop table to it, and DB taking care of flushing
those automatically (with internal logic ., may be gc). However, with mutable
property set to true, my work still be there of clearing all 10k records + port
record in same commit txn, I feel that is large txn (sorry if I am
exaggerating). Regarding the constraint violation, I viewed it as we didn't
modified the column actually, when the txn violated the constraint, the
corresponding row has been deleted and the DB is brought stable due to that. I
could be wrong here, for me it looks like a nice feature to have.
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.
ELMOHAN> Got it Ben. You mean, flush all entries and port record in same commit
txn, so, if I have 16k route entries that are pointing to one port record with
strong reference I can delete 16k+1 records with atomicity guaranteed? I am
coming from ops-quagga perspective, if you need the context of my conversation.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
