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

Change references to "populations" in API to "ancestry groups" #1457

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

phildarnowsky-broad
Copy link
Contributor

@phildarnowsky-broad phildarnowsky-broad commented Mar 27, 2024

Old fields are still supported but are now marked as deprecated. Frontend queries are also updated in the interest of eating our own dogfood, though due to the difficulty entailed in finding out systematically which queries use a given field, it's possible there are still some references to populations in some. Also, in the interest of keeping this PR down to a reasonable size and timeframe, I mainly did not address changing variable names in non-user-facing code, just where it was necessary to make e.g. deserialization of GraphQL responses come out correctly. The frontend has been left alone for now for reasons described in a comment below.

genes: [String!]
length: Int
ancestry_groups: [CopyNumberVariantAncestryGroup!]
populations: [CopyNumberVariantPopulation!] @deprecated(reason: "Use ancestry_groups")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This field deprecation story is one of the nice things about GraphQL I have to say.

Old field names will still work (don't want to break anyone else's gnomAD clients) but are now marked deprecated.
This is prep to changing its "populations" field to "ancestry_groups".

Note that, following the GraphQL API schema, "length" and other fields that don't seem like they should be null-able can be null. We should check the actual data, ensure there's no nulls in the fields in question, and assuming not tighten these types up.
Trying to do this systematically with the unstructured queries we have is proving to be error-prone and risky.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants