Operating System: All
Platform: All

I assume that the prerequisite is also that the "unique" statement is exposed by the YANG parser (e.g. in ListSchemaNode), which is currently not the case.

Will this also be fixed by this bug? Or should a separate bug ticket be submitted?

(In reply to Peter Verthez from comment #1)
> I assume that the prerequisite is also that the "unique" statement is
> exposed by the YANG parser (e.g. in ListSchemaNode), which is currently not
> the case.
>
> Will this also be fixed by this bug? Or should a separate bug ticket be
> submitted?

Please create a separate bug with dependency to this bug.
Thanks.

ok, https://bugs.opendaylight.org/show_bug.cgi?id=5946 submitted

From data management perspective, YANG defines two concepts which ensure a logical combination of leaves is unique.

The key statement is equivalent to an SQL primary key. Each list entry must have a unique combination of leaves specified by the key statement argument. These leaves must be immediate part of the list entry. Also, much like a SQL primary key, it acts as an index, allowing quick access to specific entries – which we achieve by storing list items in Maps keyed by NodeIdentifierWithPredicates.

The unique statement is similar in that it defines a combination of leaves which has to be unique – very much like an SQL UNIQUE constraint. There are two differences:

• every container/list can define multiple unique statements (as opposed to a single key)
• leaves in a unique statement can target any descendant leaf

Given the following model:

list foo {
key bar;
leaf bar;

container baz

container qux

unique "baz/baz qux/qux";
}

the implementation challenge is to efficiently detect when a write to 'leaf baz' triggers a constraint violation while allowing it to be over-written with the same value.

A naive implementation would require a full scan of 'list bar' to establish if there are any conflicts. This is obviously not feasible if the list has a million entries and most of them do not even have 'leaf baz'.

Hence our implementation needs to maintain a set of indices (Maps?) which will allow us to realize that a leaf is part of a unique statement and create the corresponding unique key. This will then need to be looked up to see if a conflicting entry exists.

Note that this is a simplistic example, YANG does seem to allow for absolute paths to leaves and nested lists, which are bound to complicate the lookups. For an initial prototype we need to handle the case above and then we can evaluate how to extend it to full compliance.

Once we have the indices working internally in the DataTree, we need to think about how to allow users to use them, as a common request from application developers is to read the list entry which matches a unique constraint – e.g. they know the values of leaves in the unique statement without knowledge of the primary key.

https://git.opendaylight.org/gerrit/#/c/40145/