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

[ChristopherEeles]

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

[mnakano]

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

[ChristopherEeles]

Hi Minoru, Yes the solution you have outlined will work. We can probably tie it to the Bioconductor releases in Spring and Fall. I guess it doesn't really matter if we use the PharmacoGx or Bioconductor release version, but my first instinct is to use the Bioconductor version since this is what BiocManager uses to determine the correct package to install/load. For this release we would need a version for 3.13 and 3.14 (release and development, respectively). Because the spring release builds both branches with the same version of R (4.1.0), the two version could point to the same page. For the fall release, we will need two separate pages, since the development branch will start using R 4.2.0. I guess the next question is do we want to implement this retroactively? I have a meeting with Petr this afternoon so I can talk to him then to get his thoughts. Best, Chris From: mnakano ***@***.***> Sent: June 1, 2021 10:28 AM To: bhklab/ORCESTRA ***@***.***> Cc: Christopher Eeles ***@***.***>; Author ***@***.***> Subject: Re: [bhklab/ORCESTRA] Use of OCRESTRA API end-points break backwards compatibility in PharmacoGx? (#22) 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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.orcestra.ca%2Fpsets%2F%255Bcanonical&data=04%7C01%7C%7C3be09052fd21402b62ff08d925096ac9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637581544632303623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jB0Oktgrq5wy2Lbby1RdqKP84in1KjrPrFRIXPcVi6Y%3D&reserved=0> or available] 2. The modified version will have an additional 'version' parameter: https://www.orcestra.ca/psets/[canonical<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.orcestra.ca%2Fpsets%2F%255Bcanonical&data=04%7C01%7C%7C3be09052fd21402b62ff08d925096ac9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637581544632303623%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jB0Oktgrq5wy2Lbby1RdqKP84in1KjrPrFRIXPcVi6Y%3D&reserved=0> 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 - You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbhklab%2FORCESTRA%2Fissues%2F22%23issuecomment-852171000&data=04%7C01%7C%7C3be09052fd21402b62ff08d925096ac9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637581544632313586%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PtnLhM6TJZ4xjijvUBqB9%2BVgkwJvxvRA3IBz4KF7jp8%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKVOS26J64MWVTIJPIDSYKTTQTU55ANCNFSM453LMYIQ&data=04%7C01%7C%7C3be09052fd21402b62ff08d925096ac9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637581544632313586%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=elvwmpclzwTRCf6rXfla%2BOVMz9i3cEzm7EStLG46qGc%3D&reserved=0>.

[mnakano]

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.

[ChristopherEeles]

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.

[mnakano]

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?

[ChristopherEeles]

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.

[mnakano]

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.

[ChristopherEeles]

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 🙂