le_cfg_DeleteNode operation

Hiya,

I’m having some issues with le_cfg_DeleteNode() not appearing to work correctly.

My intention is to completely replace a subtree when new data is received by the module (via AirVantage in this case, but that’s not the issue this time).

If I do the following:

iter = le_cfg_CreateWriteTxn("/v1/mydata");
le_cfg_DeleteNode(iter, "");
le_cfg_CommitTxn(iter);

then my subtree /v1/mydata and all child nodes is deleted (as shown by using config get myapp:/ in a console window

However, if I delete the node and then write new data into the tree like so:

iter = le_cfg_CreateWriteTxn("/v1/mydata");
le_cfg_DeleteNode(iter, "");
le_cfg_SetInt(iter, "/v1/mydata/myIntB", 5);
le_cfg_CommitTxn(iter);

Then old data (such as /v1/mydata/myIntA) from previous instance of the config tree is still present, even after the delete().

Does there need to be a time delay after the delete() before I start writing to the tree again? If so, this is not documented in the on-line docs.

Can anyone enlighten me why this is happening?

ciao, Dave

Have you tried doing this?

iter = le_cfg_CreateWriteTxn("/v1/mydata");
le_cfg_DeleteNode(iter, "");
le_cfg_CommitTxn(iter);
iter = le_cfg_CreateWriteTxn("/v1/mydata");
le_cfg_SetInt(iter, "/v1/mydata/myIntB", 5);
le_cfg_CommitTxn(iter);

I haven’t looked at the config tree code in detail, but I’m wondering if there is a bug where the delete of the entire subtree is canceled if a new node is subsequently created before the transaction is committed.

Hiya,

@dfrey Yep, that works - but it’s not what I need/want to do. I’ve got two problems doing it this way:

  1. I have other components with listeners attached to bits of the config tree - doing the delete/replace this way causes two (potentially time consuming) events to be fired - one of which is going to be a ‘null’ event when the sub-tree is deleted.
  2. I’m trying to do an in-place update of config information received over the air. Wrapping the delete/update process in a Transaction should give me to opportunity to roll-back if the data received over the air is corrupt or invalid in some way.

I guess I read the word ‘transaction’ in the doco as if it worked like a database transaction - can do pretty much what you want to the data after a ‘BEGIN’, but the data is not changed until a ‘COMMIT’. Doesn’t appear that this is the case when a delete is involved… Sigh.

Finally, I’ve also had trouble reading the configuration tree as written by the application using the command line config command. What config reports and what the application reads back are sometimes not the same. This too is a nuisance.

Oh, and I’m still working with 16.10.1 - I’m using a FX30 at the moment.

ciao, Dave