OVSDB supports 2 types of cross-table references: strong reference and **weak"" one.
in the case of "strong" references, the allowed UUIDs are limited to UUIDs for rows in the named table.
for "weak" references there is not this restriction/guarantee, any UUIDs are allowed, but UUIDs that do not correspond to rows in the named table will be automatically deleted.
"refTable" constraints are "deferred" constraints: they are enforced only at transaction commit time
RFC 7047 allows columns that contain weak references to be immutable. Since version 2.6, ovsdb-server forces columns that contain weak references to be mutable.
OVSDB schema specifies the "isRoot" boolean attribute per-table, which is used to determine whether rows in the table require strong references from other rows to avoid garbage collection.
If "isRoot" specified as true, then rows in the table exist independent of any references (they can be thought of as part of the "root set" in a garbage collector).
If "isRoot" is omitted or specified as false, then any given row in the table may exist only when there is at least one reference to it, with refType "strong", from a different row (in the same table or a different table).
This is a "deferred" action: unreferenced rows in the table are deleted just before transaction commit.
OVSDB supports 2 types of cross-table references: strong reference and **weak"" one.
"refTable" constraints are "deferred" constraints: they are enforced only at transaction commit time RFC 7047 allows columns that contain weak references to be immutable. Since version 2.6, ovsdb-server forces columns that contain weak references to be mutable.
OVSDB schema specifies the "isRoot" boolean attribute per-table, which is used to determine whether rows in the table require strong references from other rows to avoid garbage collection.
This is a "deferred" action: unreferenced rows in the table are deleted just before transaction commit.