[Question] How to read attributes of `type`

[bedrich-schindler]

Hi,

I would like to ask you whether it is possible to read attributes of the type. For example, we would like to access pattern of the string type, but I haven't found a way how to do it.

Reason is that we use libyang compiled to WebAssemble, we transform YANG schema to JSON representation of YANG schema and we would like to validate simple validations like pattern, min, max on frontend while YANG always returns only 1 error during the validation phase.

Code snippet

I have following code (simplified):

libyang::Leaf leaf = ...;
auto dataRawType = leaf.valueType().name();
auto dataRawTypeDescription = leaf.valueType().description().value_or("");
auto pattern = ???; // How to obtain pattern?

Default type

type string {
  pattern '[\-a-z0-9]{3,100}';
}

Custom type

  typedef node-id {
    description "ID of the node";
    type string {
      pattern 'N\d+';
    }
  }

leaf id {
  type node-id;
}

Any hint or it is not supported yet? I have elementary level of C++ (and C), but it might be enough to publish m_type/m_typeParsed using some getter so we can at least make workaround on C level if it is not supported.

Thank you for your help and contribution to open source!

[syyyr]

Hi,

as of now, the pattern field of m_typeParsed isn't available (and many others also).

but it might be enough to publish m_type/m_typeParsed using some getter so we can at least make workaround on C level if it is not supported.

That would solve the problem, at least until better support for lysp_type is added. Unfortunately, I have some problems with my Gerrit account, so I can't submit a patch for a getter (cc @jktjkt). However, it shouldn't be difficult to write a getter function. It would look similar to the getRawNode function.

Also, be sure to create your libyang context with the libyang::ContextOptions::SetPrivParsed, otherwise you won't have access to the parsed type info.

[bedrich-schindler]

We do not have problem to create a such patch (speaking about m_typeParsed) if necessary. But if you modify code out of Github (I do not know Gerrit), we would be more than happy to find such patch in upcoming week(s) :)

Thanks for info, we already use libyang::ContextOptions::SetPrivParsed otherwise it throws an error.

[mbohal]

I'm also struggling with this. Is there any way I could help to make this happen?

[jktjkt]

Apologies for a late reply, real life happened.

we would like to validate simple validations like pattern, min, max on frontend

I suppose this will also need exporting the range statement, etc. Patches welcome :).

while YANG always returns only 1 error during the validation phase.

I thought that libyang tries to export all of the validation error which are found via Context::getErrors() -- can you confirm whether you're getting all of them, or whether some are missing? I can imagine that there are scenarios where some errors are "masked out" due to previous validation errors preventing further processing, but that should only affect very complex scenarios with unions, etc. Or I might be wrong. Can you please bring this to upstream (libyang)'s attention?

Anyway, I understand that it's always nice to provide early, if possibly incomplete, validation directly on a frontend, so here's a patch, please report there (or here) whether it's enough for your use case:

https://gerrit.cesnet.cz/c/CzechLight/libyang-cpp/+/5891

I have not tested how it plays with a chain of typedefs, etc, so there might be some nasty surprises still lurking around.

Also keep in mind that the YANG regular expressions have a well-defined semantics, and that e.g. the OpenConfig models use them in a non-YANG-compliant way (pattern anchored vs. non-anchored, but there's more unfortunately). Also, there's been some recent changes in libyang itself which fixed some Unicode-related bugs.

[michalvasko]

Can you please bring this to upstream (libyang)'s attention?

It should be like you said and if some errors are missing, we would need the exact use-case and problem. You can create an issue in libyang with all this information.

[bedrich-schindler]

I suppose this will also need exporting the range statement, etc. Patches welcome :).

Yeah, you are right. Thank you for the patch. I will learn how to contribute to your repo on Gerrit and will create patches containing those changes in upcoming weeks.

Can you please bring this to upstream (libyang)'s attention?

It should be like you said and if some errors are missing, we would need the exact use-case and problem. You can create an issue in libyang with all this information.

We would open issue in libyang if problem lasts.

[Laguna1989]

For future reference

libyang::Leaf leaf = ...;
if(leaf.valueType().base() == libyang::LeafBaseType::Uint8) // or any other numeric type from libyang::LeafBaseType
{
    auto const num = leaf.valueType().asNumeric();
    auto const range = num.range();
    if (!range.parts.empty()) 
    {
        auto const min = range.parts.front().first;
        auto const max = range.parts.front().second;
    }
}

You can then use std::holds_alternative<uint8_t>(min) and std::get<uint8_t>(min) to check and get the actual values from the variant.