Re: [YANG] deep keys and unique statements

Ladislav Lhotka <lhotka@cesnet.cz> wrote:
> Andy Bierman píše v Pá 18. 01. 2008 v 08:23 -0800:
> > On the other hand, the unique-stmt allows arbitrary combinations
> > of leaf instances anywhere within the list.  The complexity
> > built into the unique-stmt is extensive, as even a 2-d table shows:
> 
> I am thinking about an alternative "upside-down" implementation of both
> key and unique properties, namely to declare these properties with the
> leaf. The semantics would be that these properties always pertain to the
> nearest ancestor list (if any, otherwise it is noop). Example:
> 
> list aaa {
>   container bbb {
>     leaf c {
>       type c-type;
>       unique;
>     }
>   }
> }

This doesn't work if it is the combination of two leafs that is
unique.  In this example, the name has to be unique, and also the
ip/port combination:

  list server {
    key "idx";
    unique "ip port";
    unique "name";

    leaf idx { ... }
    leaf ip { ... }
    leaf port { ... }
    leaf name { ... }
  }

[Side note: In our current DML we took the approach you describe, but
in order to handle the combinations, the unique statement took an
argument which was a tag.  All leafs with the same tag would be
checked in combination.  I think the YANG statement is more clear.]

> There are two advantages:
> 1. The scope of the property - nearest ancestor list - is always unique,
> so no XPath expressions are needed here.
> 2. At the time when the declaration is read the entire ancestor chain is
> known, i.e., no buffering is needed.

I don't understand these advantages.  Are you talking about buffering
in the compiler?

> 
> If I remember correctly, the main objection against this implementation
> is that it would be difficult to declare keys a posteriori for standard
> groupings, but I think it could be handled by extending the augment
> statement, e.g, like this:
>
> module inet-extra {
>   ...
>   grouping endpoint {
>     leaf address {
>       type inet:address;
>     }
>     leaf port {
>       type uint16;
>     }
>   }
>   ...

I think it would be the uses refinement that would be used (not augment):

  list foo {
    uses iex:endpoint {
      leaf address {
        key true;
      }
    }
  }

/martin