Giters

bhklab / ORCESTRA

ORCESTRA is a new web application that enables users to search, request and manage pharmacogenomic datasets (PSets).

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Use of OCRESTRA API end-points break backwards compatibility in PharmacoGx?

ChristopherEeles opened this issue · comments

commented

I just noticed this right now while trying to respond to a user issue for PharmacoGx.

When we migrated the availablePSets and downloadPSet functions to query the ORCESTRA API we started forcing all package users since this update to use the most recent PharmacoSet objects. This may break backwards compatibility if, for example, we migrate the data in the @molecularProfilesSlot to a MultiAssayExperiment. It may even break for new Bioconductor releases if there is a change in the object serialization in R from one release to another (e.g., as was done in version 3.5 -> 3.6), preventing users from loading PharmacoSets without updating their version of R.

Since all the previously released PharmacoSets are available on Zenodo, would it be possible to version the API URL such that we ensure users of previous PharmacoGx releases download the appropriate PharmacoSets? Then we can update the URL for each release to prevent breaking backwards compatibility. That way users get the appropriate version of the PharmacoSet for the BiocManager version.

Let me know your thoughts on this?

Chris

commented

Hi Chris,

Yes, this can be implemented at the API endpoint. The following would be the expected behaviour of the new feature, if I understand correctly:

  1. The current endpoint URL to get available PSets is https://www.orcestra.ca/psets/[canonical or available]
  2. The modified version will have an additional 'version' parameter: https://www.orcestra.ca/psets/[canonical or available]/[version]
  3. The API would use the version parameter to build a download URL for each PSet that corresponds to the version.

For the version parameter, would it be the PharmacoGx version?

Minoru

commented
commented

Hi Chris,

The latest deployment includes changes to handle multiple DOIs/download links for one data object depending on BioConductor release versions as follows:

  1. The API end point URL can be used as it is, for example /api/psets/canonical.
  2. It can have version query where the BioConductor release version would be passed: /api/psets/canonical?version=3.13.
  3. The current default (and only) version is set to 3.13.
  4. If no version is passed, the API returns data objects with DOI and download link for the current default version.
commented

Hey Minoru,

I guess one complexity will be ensure the API still works when new releases occur. I think I can handle that in the R code right now by using a tryCatch block and decrementing the version until it find a match from the API.

As long as that works this should resolve this issue.

commented

Hi Chris,

Ok sounds good. With the current implementation, the API will return an empty array if no version is found.
Is there anything more useful to return for the PharmacoGx side if this is the case?

commented

No that is probably fine. The default will always be the highest available version right? I can just fall back to the default if I don't get results from my first call.

commented

Yes, it's intended to always be the highest version. The default value is controlled by the app's environment variable, so when we decide to change the default version value, all we need is to change the app's configuration value on Azure, and everything should work as is, provided that we have updated the database by adding the DOI and download link of the corresponding new version of the data objects.

commented

Yea that should meet all my needs in PharmacoGx then. I will close this issue once I have the updates pushed to Bioconductor and tested.

Thanks for your help 🙂