How do you create a node with multiple keys?

[nullromo]

I have a yang model that looks like this:

list my-list {
    key 'key-a key-b';
    leaf key-a {
        type string;
    }
    leaf key-b {
        type string;
    }
    leaf style {
        type enumeration {
            enum style-a;
            enum style-b;
        }
    }
}

I should be able to access the style of an item in my-list using one of these paths:

1. "/my-list[key-a='hello' and key-b='goodbye']/style"
2. "/my-list[key-a='hello'][key-b='goodbye']/style"

This normally works when getting data out of my datastore.

However, I am now trying to create nodes using lyd_new_path, and running into an issue. I tried calling lyd_new_path with these paths and I always get LY_EVALID as the return code. Example:

int rc = lyd_new_path(NULL, context, "/my-list[key-a='hello'][key-b='goodbye']/style", "style-a", 0, NULL);

For lists with 1 key, this method has been working. What is the proper way to create new nodes when the list has multiple keys?

[nullromo]

After stepping through the libyang code using gdb, I was able to determine that the predicate checking function specifically looks for the [ character, then the name, then the = character, then a literal, and finally the ] character. So the syntax using and is not allowed. After that, I later determined that my key-b was specified as [key-b=1] instead of [key-b='1'] (it was not quoted). After fixing these issues, the function worked.

[michalvasko]

You could have simply looked at the error message but whatever works for you. Also, it is quite well documented I would say, the path parameter takes you to this page in its description. There you have a specific example of list with 2 keys, among others, so I really do not know what more to do.

[nullromo]

Below is an exact replication of the entire error message:

Validation failure

All I have to work with is the return code from the function itself, which is LY_EVALID.

I think the documentation is quite clear, yes. Also, thank you for pointing out the specific pages. I just didn't know the exact issue and I spent a long time testing many variations of paths that I thought were valid based on my (then incorrect) understanding of path/xpath. Now I have reviewed the path/xpath documentation again and I understand it better.

I figured posting an answer to my question was better than leaving it unanswered or simply deleting the discussion, but feel free to delete it if you'd like.

[michalvasko]

No problem with you posting the answer, I am just trying to figure out if there is anything to improve so that the next person does not have this problem. And I do not see anything.

All I have to work with is the return code from the function itself, which is LY_EVALID.

This is not true, there is a specific error message printed but maybe you do not have logging to stderr enabled. There are quite a lot of logging options so it is possible.

[nullromo]

Thank you for pointing me on the right path. I read in the "Information Logging" page of the docs that "by default, all libyang messages are printed to stderr," so I thought it would have been printed already. I tried adding ly_log_level(LY_LLDBG);. That did not cause any additional messages to show up. Then I also read from the description of LY_LOLOG that "if [the callback is] not set, messages will not be printed by libyang." So then I tried adding a callback, but the function did not get called. Finally, I tried verifying that the ly_log_options function was returning a value with the LSB set (i.e. a value that contains the bit for printing messages), and it wasn't. So after adding ly_log_options(LY_LOLOG), the error messages do show up.

The "default" logging options are LY_LOLOG | LY_LOSTORE_LAST, but I found that mine was set to LY_LOSTORE instead.

I found that this was because I use sysrepo and I had previously called sr_log_stderr(SR_LL_DBG);. There is a note in the sysrepo docs for sr_log_stderr that says "please note that this will overwrite your libyang logging settings." Reading that, I thought that setting my sysrepo log level to DBG would mean that libyang also gets set to DBG, and that I would get all the debug messages, including from libyang. But instead, sr_log_stderr sets the libyang debug options to LY_LOSTORE, which suppresses the libyang messages.

Is this intended? I would think that setting the log level to DBG at the "higher" level (sysrepo) should enable verbose logs at the lower level (libyang). Perhaps there could be more options to pass into the sr_log_stderr function, or perhaps an additional note that says how to enable both sysrepo and libyang messages. In any case, I now understand better how the logging works :)

[michalvasko]

Yes, what you observed is intended because sysrepo uses specific logging and printing all libyang messages directly is not expected and would clutter the output. Moreover, libyang errors are often processed directly by sysrepo so printing the original messages is again not desired. That is why the messages are only stored and later retrieved from the context. However, this works only for errors and warnings and that is why you do not see any other libyang messages.

As for what to improve, the description is intentionally fairly generic so that when something changes, we avoid forgetting to update the information and for it to be misleading.

Reading that, I thought that setting my sysrepo log level to DBG would mean that libyang also gets set to DBG, and that I would get all the debug messages, including from libyang.

I do not think this was implied in any way. What it meant to hint was simply that libyang logging options will also be changed so if you want to have your own, you need to set them after setting sysrepo logging. But note that removing LY_LOSTORE option would make sysrepo confused and possibly print some invalid errors.