# Control the commit order

**URL:** <https://dmap-community.ductus.global/t/control-the-commit-order/628>\
**Category:** CDB and CDB API\
**Created:** [August 11, 2016, 12:04pm UTC](https://dmap-community.ductus.global/t/control-the-commit-order/628 "2016-08-11T12:04:34Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![yogevc](https://avatars.discourse-cdn.com/v4/letter/y/8491ac/32.png) [@yogevc](https://dmap-community.ductus.global/u/yogevc)\
**Post date:** [August 11, 2016, 12:04pm UTC](https://dmap-community.ductus.global/t/control-the-commit-order/628/1 "2016-08-11T12:04:34Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jjohansson](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@jjohansson](https://dmap-community.ductus.global/u/jjohansson)\
**Post date:** [August 11, 2016, 1:34pm UTC](https://dmap-community.ductus.global/t/control-the-commit-order/628/2 "2016-08-11T13:34:13Z")

</div>

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”.

---

<div class="post-metadata">

**Author:** ![jjohansson](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@jjohansson](https://dmap-community.ductus.global/u/jjohansson)\
**Post date:** [August 11, 2016, 2:15pm UTC](https://dmap-community.ductus.global/t/control-the-commit-order/628/3 "2016-08-11T14:15:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![yogevc](https://avatars.discourse-cdn.com/v4/letter/y/8491ac/32.png) [@yogevc](https://dmap-community.ductus.global/u/yogevc)\
**Post date:** [August 14, 2016, 11:03am UTC](https://dmap-community.ductus.global/t/control-the-commit-order/628/4 "2016-08-14T11:03:37Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![yogevc](https://avatars.discourse-cdn.com/v4/letter/y/8491ac/32.png) [@yogevc](https://dmap-community.ductus.global/u/yogevc)\
**Post date:** [August 16, 2016, 9:19pm UTC](https://dmap-community.ductus.global/t/control-the-commit-order/628/5 "2016-08-16T21:19:06Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![cohult](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/cohult/32/221_2.png) [@cohult](https://dmap-community.ductus.global/u/cohult)\
**Post date:** [August 22, 2016, 8:01am UTC](https://dmap-community.ductus.global/t/control-the-commit-order/628/6 "2016-08-22T08:01:17Z")

</div>

Hi,

> [@yogevc](#):
>
> I didn’t see a callpoint-order as in a ordinary subscription.

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.