You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to RFC 7950, section 7.6.7, the replace operation is intended to behave as a combination of delete and create. In the context of a operation, this implies that if a leaf does not exist and is targeted with replace, it should be created.
However, when using lyd_diff_apply_all() with a diff that includes a replace operation on a non-existent leaf, the function returns an error instead of creating the leaf node.
Example:
leaf foo {
type string;
}
If the current data tree does not contain foo, and the diff contains a replace operation like foo = "bar", the operation fails rather than creating the foo node with the new value.
Question: Is this the intended behavior in libyang, or is this a deviation from RFC 7950?
Thank you in advance for your clarification!
The text was updated successfully, but these errors were encountered:
Be careful, libyang defines functions for diff, which is something else than edit. The latter should fully conform to edit-config operations and is used in sysrepo/netopeer2. diff is a proprietary format representing "resolved edit" meaning every create operation must actually create data, every remove remove them, and every replace replace them.
Hello, and thank you for your work on libyang!
According to RFC 7950, section 7.6.7, the replace operation is intended to behave as a combination of delete and create. In the context of a operation, this implies that if a leaf does not exist and is targeted with replace, it should be created.
However, when using lyd_diff_apply_all() with a diff that includes a replace operation on a non-existent leaf, the function returns an error instead of creating the leaf node.
Example:
If the current data tree does not contain foo, and the diff contains a replace operation like foo = "bar", the operation fails rather than creating the foo node with the new value.
Question: Is this the intended behavior in libyang, or is this a deviation from RFC 7950?
Thank you in advance for your clarification!
The text was updated successfully, but these errors were encountered: