Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 should be PROGRAM_ID not STUDY_ID #253

Closed
rosibaj opened this issue Jun 12, 2020 · 3 comments
Closed

🐛 should be PROGRAM_ID not STUDY_ID #253

rosibaj opened this issue Jun 12, 2020 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@rosibaj
Copy link
Contributor

rosibaj commented Jun 12, 2020

In the file repository, there program_id field is mislabeled.

study_id comes from song, but it should be transformed to be consistent with the rest of the Argo API.

image

@rosibaj rosibaj added the bug Something isn't working label Jun 12, 2020
@rosibaj rosibaj removed their assignment Jun 15, 2020
@rosibaj
Copy link
Contributor Author

rosibaj commented Jun 17, 2020

  • not very confident of doing a transformation in graphql only.

  • One complication I can see right now is in the sqon, where all the field references are expecting to be Elasticsearch document fields. So if we just change graphql field without the underlying mapping, there’ll be a discrepancy between the graphql fields and the sqon.

  • So without changing the underlying mapping, I’m not sure there’s anything we can (or should) do there… If we really need this transformation without a mapping change, it should be an arranger configuration feature, which really won’t be done in time.

  • An alternative to doing this in any application layer (gateway or arranger), is we can add a program_id field to the mapping, without removing the study_id field, that way the UI can run its queries and build sqons on program_id rather than study_id, then I can look into whether there’s a way to hide study_id in the gateway schema

@rosibaj
Copy link
Contributor Author

rosibaj commented Jun 18, 2020

@kcullion
Copy link

Spoke to @joneubank and we will close this as it's more work than what it's worth.

changing it will necessarily involve choosing where to stop changing it. it makes sense that the public interface would use program but unfortunately that means its a change in the file-centric index which relies changing code all the way back to file service…its more trouble than its worth i think

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants