... especially those objects extending Entity.
The rPython package uses json.dumps() to serialize results before passing to R. For this to work with the synapse client, any object that comes back from a public function in the synapse python client would have to be serializable by json.dumps().
Since we have now decided to use the pythonInR package instead, JSON serialization is no longer necessary. This new package can pass python object references/pointers to R.
I would like this feature for different purposes and different philosophies. I want to be able to use our JSON representation of Synapse entities to bootstrap from a template to create new things. For example, I have a series of Projects with specific relationships, default file views, and annotations. I want to be able to record the template in a standard fashion, and use it to instantiate new projects. It would be simplest if I could inspect an existing project, dump it's representation to JSON, make manual changes, and use this new JSON to create new entities. I can do this for some things. However, if you try to serialize annotations with 'datetimes' in them, it breaks.
I think, from a RESTful and FAIR perspective, all of the things we return should come as their standardized definition, which we have in JSON.
Before going further I would want to understand your use case and approach further. It sounds like you are saying that there is value in having access to the serialized JSON that comes from the Synapse back end (as opposed to using the Python objects generated from the serialized JSON by the Python client). If this is correct I wonder if it might be better to tap in to that serialized representation before it is turned into Python object(s) rather than seeking to re-serialize the objects. Here is an example using the current client:
True. Let me ponder how that would work, and if there's anything that the client itself is doing that I need it for. Thanks for that suggestion!
I may bring up this topic again in my refactor work on the Synapse Python client to ensure that the code base is clean and have consistent behaviors (SYNPY-882). However, it seems like there is no actual issues to be addressed by this ticket. So I am resolving it as Won’t Do.