Add support for instance-identifier
My goal was at least to make basic R/O operation work with ietf-alarms.
Then I didn't have an easy way of testing this code, so I made it work
for editing as well.
Limitations:
- You can set an instance-identifier which points to an input node of an
RPC/action, which sounds fishy, but that could be a libyang bug.
- Non-config lists works funnily, which might point to a bug somewhere
in our handling of data paths:
/> set example-schema:iid-valid /example-schema:users/userList
libyang[0]: Unexpected XPath token "]" ("]"). (path: Data location "/example-schema:iid-valid".)
libyang[0]: Invalid instance-identifier "/example-schema:users/userList[]" value - syntax error. (path: Data location "/example-schema:iid-valid".)
The following errors occured:
Message: Invalid instance-identifier "/example-schema:users/userList[]" value - syntax error.
XPath: Data location "/example-schema:iid-valid".
- XPath says that any key value must be quoted, but the CLI reuses the
existing leaf_data_ parser for list keys (even prior to this patch),
which means that a list indexed by, say, an enum looks like:
/example-schema/list[val=666]
...which is not a valid XPath. A valid XPath would look like this:
/example-schema/list[val='666']
This new feature hits the same problem; when the instance-identifier
gets parsed from the user's input and converted to a string, the usual
netconf-cli rules are followed, and the list keys are not quoted
unless they are strings. This means that these values cannot be stored
or committed because libyang correctly rejects unquoted key values in,
say, instance-identifier values.
Quite frankly I'm not even sure how come that this has not been a
problem during normal operation, but perhaps it's only because we've
always tested with string-based lists and nothing else. Sure, we have
partial unit tests for all sorts of data types, but nothing actually
checks the full stack from the parser's input all the way to a
backend.
Path completion was a challenge for me to get right. At first I wanted
to use a different, fresh ParserContext to make sure that we do not
affect the main (leaf) path's state at all. That did not work well even
when I tried to copy the "relevant" memebrs of ParserContext back to the
original parser. But it turns out that simply reusing the existing
ParserContext works perfectly well. The only caveat is the concept of
"cwd", where a leaf below a certain container would "expect" paths that
are relative to the original cwd (which means "not root"). That's just
broken. The easiest fix is to always enforce an absolute path. The
easiest way of getting there was a yet another "parser mode" for
absolute-paths-only.
Yay for the immediately-invoked-lambda, because I really wanted to use
an constexpr if in there.
Change-Id: I68302ad854eab43aa6c42dcb2693b71ca3d2bd48
Depends-on: https://gerrit.cesnet.cz/c/CzechLight/dependencies/+/6445
diff --git a/src/leaf_data_type.hpp b/src/leaf_data_type.hpp
index c3c30c9..f1619ec 100644
--- a/src/leaf_data_type.hpp
+++ b/src/leaf_data_type.hpp
@@ -71,6 +71,10 @@
std::set<std::string> m_allowedValues;
};
struct LeafRef;
+struct InstanceIdentifier {
+ InstanceIdentifier();
+ bool operator==(const InstanceIdentifier& other) const;
+};
struct Union;
using LeafDataType = std::variant<
yang::String,
@@ -90,6 +94,7 @@
yang::IdentityRef,
yang::Bits,
yang::LeafRef,
+ yang::InstanceIdentifier,
yang::Union
>;
struct TypeInfo;