Reduce complexity in handling Synapse objects

Description

When user create an Entity, the Entity object is initialized and passed to other functions (store, get, ...) However, when getting data from PLFM, the client do not always map the returned object back to a meaningful defined instance in the Synapse Python client. Instead, every returned object was a dictionary. Then everywhere in the code that need to handle a certain type of Synapse object, there are switches to figure out if the input was of a specific type, or contains certain key/value pairs. This is poor implementation and should be refactor/ clean up.

Notes to self: it would be great if the Synapse objects in the client can have the following features:

  • have hashcode() and equals() – so that we easily compare the objects in tests.

  • DictObject was designed for entity annotations (as in its documentation). However, it was implemented by the following objects in the Python client:

    • Entity's properties

    • Entity's annotations

    • FileHandle

    • Entity's local state

    • Evaluation

    • Submission

    • SubmissionStatus

    • SelectColumn

    • Column

    • AppendableRowset

    • Row

    • PartialRow

    • UserProfile

    • UserGroupHeader

    • Team

    • TeamMember

    • Wiki

    • WikiAttachment

    • other Synapse returned objects by the following functions:

      • client.py::getWikiHeaders()

      • multipart_upload.py::_start_multipart_upload()

      • multipart_upload.py::_add_part()

      • multipart_upload.py::_complete_multipart_upload()

TODOs:

  • give summary of how Python users think about/ would like to interact with Synapse objects.

Environment

None

Activity

Show:
Bruce Hoff
March 17, 2020, 10:47 PM

. For your consideration: Should we do what's proposed here?

Your pinned fields
Click on the next to a field label to start pinning.

Assignee

Jordan Kiang

Reporter

Kimyen Truong

Labels

Validator

Kenneth Daily