Reordering of a list

Hi!

I need to reorder my list because I need to save a part of my configuration in a non-alphabetical order.
I already have a set-hook defined for the list. Set-hook handles create and delete callbacks.
I have trouble understanding which other callbacks i need to implement. to me it makes sense to only implement get_next(), looking at the user guide I see that callback move_after is mentioned.
I could not find any CDB API examples with “ordered-by user”.
Can you please help?
BR Jaka

For plain “ordered-by user” you should not need to define any callbacks. The list instances are stored in the order as they are entered, you may reorder them if needed. Have a look at the “ordered” example.

Or is your use-case more complex?

Hi mvf and sorry for late reply!

I can’t grasp the whole picture regarding the reordering of a list. As I read the user manual i got a couple of ideas how I think confd can be made to do reordering. Can you please comment on the list bellow regarding if the points are feasible?

  • create get_next cb via set hook or transaction hook?

  • create move_after cb via set hook or transaction hook?

  • use maapi_move_after inside create cb?

p.s. I haven’t tried your suggestion yet and will reply when I do.

Yes reordered-by user is a fine solution, thank you. There is only one problem which is that upgrade fails. Is this something that is very possible or is it just a bug in our implementation.
p.s. could you please elaborate a bit on the points from the previous comment

I am not aware of any issues with upgrading lists configurations from ordered-by system (the default) to ordered-by user; so I’d say it is something in your application.

As for the callbacks - I still fail to see why you think you need them. Once your list is ordered-by user, you may order the list entries from CLI, using NETCONF, or from an application, no callbacks of any sort needed.

The upgrade fail is due to our validation. Must statement references leaves that are defined further down the container and the must statement sees them as “not set”.
The reason i’m mentioning callbacks is because I think that the cases I mentioned (if they are feasible) are not very well elaborated in the User Guide (still a huge fan of User Guide). I wanted to know if they are wrong without having to implement a test case.

I see. The list of callbacks that you need to implement for a set/transaction hook is not really related to how list ordering is managed; if your use-case does not require move_after, simply do not implement it - confd only invokes those callbacks that your application advertises in confd_register_data_cb.

If you are not sure if you want set hooks or transaction hooks, it probably means you should use transaction hooks - they have much clearer semantics of when they are invoked and how failures are handled. Set hooks can be pretty troublesome in this respect and should be used with care.

In my case it’s really important that a specific list entry is always the last entry in the list (even if some other entries are added at later time than this particular entry). Can you please give me a recipe to utilize move_next callback, if that would be a good approach?

If only that specific entry needs special care, maybe ordered-by user is an overkill, especially if that means that you need to take care of ordering other entries. In a similar situation we used trickery with user-defined types (see the corresponding section in confd_types manpage) and made sure that the specific entry was ordered always as the last.

If you think order-by user is fine, you may really need to register some transaction hook callbacks - those that may change the ordering, which is probably create and move_after. In that callback you would use maapi_move_ordered to shuffle entries, if needed. The problem with this is that such shuffling might recursively invoke your callback again; if you implement this part carefully, it might work, maybe.

Another variant - provide your list as a “virtual view”, i.e transformed view of a real CDB-stored list. This way you may have complete control over how list entries are stored (or how they are presented to the user, depends on what is your main concern). It would require more coding then the other variants, but it might be considerably safer.

Thank you for your help!
I will go ahead and implement “ordered-by user” only. It turns out that will be sufficient.