Cables.serialize() is inconsistent #555
Labels
pynetbox
status: accepted
This issue has been accepted for implementation
type: bug
A confirmed report of unexpected behavior in the application
Hi,
I am currently looking at upgrading our NetBox instance to the latest version, which means jumping over 3.3 with breaking changes in the Cable model.
Thanks @arthanson for the adapted Pynetbox version 7! Seems to work well for most of our usage. However I am slightly concerned with the output of the
.serialize()
method on Cable objects.Indeed, when looking at the raw API output for a cable, we have the
object
,object_id
andobject_type
values for each of thea_terminations
andb_terminations
:However, it looks like the new
generic_list_parser
is "obfuscating" this by reconstructing a list of Rear/FrontPorts/Interfaces objects. Kind of nice, but then when you call serialize() the output is as follows:The docstring for
serialize()
says "Pulls all the attributes in an object and creates a dict thatcan be turned into the json that netbox is expecting."
I don't think this is the case here, as the POST action needs the dict structure with object_id and object_type in the termination list.
On a side note, we've implemented an extra caching layer between our app and Pynetbox where we store the raw/seralized records. When calling back this data and asking Pynetbox to reconstruct objects, we're now getting plain "Record" objects instead of Rear/FrontPorts/Interfaces because of the missing fields.
Shouldn't
generic_list_parser
keep the API structure and put the Port object into the "object" field ?The text was updated successfully, but these errors were encountered: