Check Python client code base on using PLFM object model
Description
And ensure that adding a new field in any object model in PLFM should not break the Python client in the future.
Environment
Activity
I found many places where we used this pattern:
return [UserGroupHeader(**result) for result in self._GET_paginated(uri)]
However, all constructors that was used already accept **kwargs, so we should not have any problem there. The only places that need to be fixed are the places we used Row and SelectColumn with this pattern. I will fix these places.
Discussed with Ziming about classes mentioned above:
PartialRowSet & PartialRow are constructors for the client users to use. We do not read data from the backend into these constructors.
Row is used to read backend data:
This indicates that the problem is in how we handle the dict object we get back from a http call rather than the constructor itself. Will look into all places we use **.
Checking the code and found questionable constructors for:
PartialRowset – http://hud.rel.rest.doc.sagebase.org.s3-website-us-east-1.amazonaws.com/org/sagebionetworks/repo/model/table/PartialRowSet.html
SelectColumn – http://hud.rel.rest.doc.sagebase.org.s3-website-us-east-1.amazonaws.com/org/sagebionetworks/repo/model/table/SelectColumn.html
Though PartialRowSet and PartialRow constructor already diverted from theirs backend schema.
Notes: looking into every class implementation I found that only Activity implemented the idea that the constructor takes a dict object and initialize the object using the dict data, while other class implemented **kwagrs.