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

Docs clarification: getting typeDefs #198

Open
rjendoubi opened this issue Dec 20, 2021 · 0 comments
Open

Docs clarification: getting typeDefs #198

rjendoubi opened this issue Dec 20, 2021 · 0 comments

Comments

@rjendoubi
Copy link

The section of the docs for getting typedefs by name currently reads as follows:

To get typedefs by name:

type_defs = client.typedef_guid(TYPE_NAME)
type_defs._data

First, I think the call should be client.typedef_name(...), not client.typedef_guid(...)`.

Secondly (and please correct me if I'm misunderstanding), the above doesn't seem to do anything. Calling the internal variable _data seems to just return a 1-element dict, with the key as name (if using the correct method) and the value being the name passed - no interaction with the server has taken place:

>>> td = client.typedef_name("does-not-exist")
>>> td._data
{'name': 'does-not-exist'}

Rather, the way to ensure actually get the typedef seems to be to call .inflate(), or any valid data attribute other than the one indicated by the method call; i.e., if client.typedef_name(...) was called, a subsequent attempt to access the guid attribute on the result will lead to a server roundtrip - or vice versa. And it is only if this call returns null that you know you've specified a typedef name which doesn't exist:

>>> td = client.typedef_name("Video")
>>> td.guid
'9708db6d-8af7-45c1-89a2-20f21ee0e5b3'  # ✔
>>> td = client.typedef_name("does-not-exist")
>>> td.guid
>>>           # ❌

Finally, it just looks a bit strange to direct users to access the internal attribute _data in the first place - in principle, surely there should be a way to achieve the same ends using some public API (even if not the approach suggested above).

If I'm not missing something here, would you accept a docs patch to clarify this section? Would be happy to extend it to the corresponding "Get [relationshipDefs|structDefs] by [GUID|name]" sections, for consistency, if you like?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant