Control the commit order

CDB and CDB API
1

Can I control the commit order when doing commit through the CLI?

container cont-a {
    leaf leaf-a {
        type uint32;
    }
    leaf leaf-b {
        type uint32;
    }
}

When entering the CLI and choosing:

cont-a leaf-a 2
cont-a leaf-b 4
commit

Is there a way to control the commit order - enforce leaf-b to be committed before leaf-a ?

Thanks

2

Only if you do
cont-a leaf-b 4
commit

followed by
cont-a leaf-a 2
commit

If you have multiple configuration changes in the same transaction (the same commit) they will happen conceptually “at the same time”.

1 Like
3

I should have added that subscription priorities exist to control the order of how configurations changes are applied. For more information, see section 5.6 CDB Subscriptions and the documentation for cdb_subscribe() in the User Guide.

4

Thanks,
That I know, but it doesn’t help me in my specific case…

5

Let me ask again:

I’ve complicated my schema a bit:

container cont-a {
    tailf:callpoint my_cb {
        tailf:transformation;
    }
    leaf password-protocol {
        type uint32;
    }
    leaf password {
        type uint32;
    }
}

I’ve added a callpoint for the container.
In this scenario I have a set_elem function.
In there I want to be able to encrypt the password leaf with the appropriate password-protocol leaf.
It means that I must know what is the password-protocol when getting to the case of set_elem the password leaf.

But there’s no guarantee for the order of the leaves - password/password-protocol.
Is there an easy way to solve it?

I didn’t see a callpoint-order as in a ordinary subscription.

Thank you very much!

6

Hi,

In your example you are using the DP / external database API as a transform application, so if the password is set before the password-protocol is changed you will probably set the password twice in the scope of the transaction using MAAPI.
First time using the password-protocol in the existing configuration, and a second time when you get the set_elem() for the password-protocol change.

If the user is changing this over for example SNMP there may be two transactions that do this, not in a single transaction over for example NETCONF. Then, if required, getting the ordering right is up to the SNMP client / manager since SNMP is not transactional.