cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
274
Views
0
Helpful
1
Replies

Pros and Cons: Single Entry List vs Container

mmalysz
Cisco Employee
Cisco Employee

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?

1 Accepted Solution

Accepted Solutions

rogaglia
Cisco Employee
Cisco Employee

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

View solution in original post

1 Reply 1

rogaglia
Cisco Employee
Cisco Employee

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