Pros and Cons: Single Entry List vs Container

mmalysz — Fri, 01 Mar 2019 11:51:26 GMT

Customer would like to have certain entities modeled explicitly withing the data model. The one below is just an example. In that case the address could be easily a mandatory leaf directly under test-service list. However for the definition of more granular structure customer wants to model certain attributes separately. In this case an entity - let's call it config-ipv4 with some attributes will need to exist for each entry in test-service list.

One way to model it will be to use list with min and max elements 1.

The other way to use non presence containers with mandatory leaf.

container test {
    list test-service {
      key service-id;
      leaf service-id {
        type string;
      }
      list config-ipv4-list {
        key address;
        min-elements 1;
        max-elements 1;
        leaf address {
          type inet:ipv4-address;
        }
      }
      container config-ipv4-container {
        leaf address {
          mandatory true;
          type inet:ipv4-address;
        }
      }
    }
}

One benefit of defining it as a container would be that in case of usage of CLI we'd be automatically asked for the value of this containers leaf. While for the list min-max elements statement we'd only receive and error at commit

What are the other pros and cons?

Re: Pros and Cons: Single Entry List vs Container

rogaglia — Wed, 31 May 2017 18:58:59 GMT

Hi,

I would think that a container is the natural choice. However, I have seen many times containers that over time evolve to lists as the service evolve. So, one point to consider is how do you imagine the model to evolve and if you could think on the need for many instances of the same data in a future.

Roque

topic Re: Pros and Cons: Single Entry List vs Container in NSO Developer Hub Discussions

Pros and Cons: Single Entry List vs Container

Re: Pros and Cons: Single Entry List vs Container