atlasclient icon indicating copy to clipboard operation
atlasclient copied to clipboard

Docs clarification: getting typeDefs

Open rjendoubi opened this issue 3 years ago • 0 comments

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?

rjendoubi avatar Dec 20 '21 19:12 rjendoubi