Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CRUD read fails during decode if top node in yang module is a list #194

Closed
ghost opened this issue Jul 22, 2016 · 3 comments
Closed

CRUD read fails during decode if top node in yang module is a list #194

ghost opened this issue Jul 22, 2016 · 3 comments
Assignees
Labels

Comments

@ghost
Copy link

ghost commented Jul 22, 2016

For the oc-pattern test yang model, the CRUD read on A() fails during decoding phase:

  File "ydk/services/crud_service.py", line 151, in read
    return provider.decode(payload, read_filter)
  File "ydk/providers/netconf_provider.py", line 87, in decode
    return self.sp_instance.decode(payload, read_filter)
  File "ydk/providers/_provider_plugin.py", line 132, in decode
    XmlDecoder._bind_to_object(payload, entity, self._get_capabilities())
  File "ydk/providers/_decoder.py", line 183, in _bind_to_object
    curr_rt = get_root(rt, entity._common_path, _yang_ns._namespaces)
  File "ydk/models/oc/oc_pattern.py", line 104, in _common_path
    raise YPYModelError('Key property a is None')
ydk.errors.YPYModelError: Key property a is None

Same issue with codec_service.decode(provider,'''<A xmlns="http://cisco.com/ns/yang/oc-pattern"> <a>Hello</a> </A>''')

@ghost ghost added the bug label Jul 22, 2016
@psykokwak4 psykokwak4 self-assigned this Jul 25, 2016
@psykokwak4
Copy link
Contributor

Currently the get_top_container_for_namespace in decoder and does not set YANG list key value, this will cause subsequent execution of _commen_path raise YPYModelError, might need to set list key value in get_top_container_for_namespace recursively.

@psykokwak4
Copy link
Contributor

In this generated API for oc-pattern test yang model, we have this leafref A.a assigned as None when initializing, is this expected behavior or a bug? Added sanity test for this but manually assign A.b.b to A.a.

@ghost
Copy link
Author

ghost commented Jul 26, 2016

I think that is expected as we initialize integers to none. The recursively setting of keys should work. Thanks for looking into this.

ghost pushed a commit that referenced this issue Jul 26, 2016
models:

      - Cisco-IOS-XR-config-mda-cfg.yang
      - Cisco-IOS-XR-lpts-lib-cfg.yang
      - Cisco-IOS-XR-lpts-pre-ifib-cfg.yang
      - Cisco-IOS-XR-types.yang
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant