diff BUGFIX check nodes before inserting after

[jeremie6wind]

The mode must be different and have the same schema.

Fixes: c80fcc9 ("diff BUGFIX diff merge userord node order")

[jeremie6wind]

Hi,
I had some errors logs while calling:

• lyd_insert_after with identical nodes
• lyd_insert_after with nodes with different schemas

I am proposing this patch, because this fixes my problem, but you surely have a better solution.
Thx
BR
J.

[michalvasko]

It would be best if you could provide (or at least describe in detail) the exact use-case so that I can reproduce it and add into the tests.

[jeremie6wind]

I attached a sysrepo patch with a sample yang module list-test.yang that I added with:
sysrepoctl --install list-test.yang

Then I started the sample:
application_changes_example list-test /list-test:state operational

Now I have 2 different sample to get the 2 cases:

1. Error log when working on the same node
   ./push_in_list_example
   It gives the error message:

[ERR] Merging operation "create" failed.

In this sample I add a list that was previously not present.

2. Error log when working on nodes with different schemas
   ./push_in_list_example2
   It gives the error messages:

[ERR] Cannot insert after a different schema node instance.
[ERR] Cannot insert after a different schema node instance.
[ERR] Merging operation "create" failed.

In this sample I change a field in the first list.

I hope it will help.
Many thanks
J.

0001-patch-to-reproduce.patch.txt

[michalvasko]

Thanks but I do not understand the use-case. The problem appears only if you try to merge and discard the same nodes in a single edit (sr_apply_changes() call) but that is correct, I think (the error should be improved but is valid), this should not be supported, why should it?

[jlesk]

Hi Mishal,
Thanks for your reply,
This worked before the commit:
c80fcc9

I understand that this is a workaround, but I am using this to 'replace' some part of the operational data and this worked so far:
sr_edit_batch
sr_discard_items
sr_apply_changes

Also changing to this would not be unitary:
sr_discard_items
sr_apply_changes
sr_edit_batch
sr_apply_changes

BR
J.

[michalvasko]

Okay, the cause was a bug so I guess the use-case can be supported, should be fixed, thanks.