5.1.0.4 model changes revised #156
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Refresh from main
Just updating this branch from main
This reverts commit 6fce4cf.
Revert "V1.3.0 (#132)"
Update versions.
All affected types implement the Annotatable interface and, thus, need to implement the dataSets field.
Specifically, attributes were added for the annotatable, bio entity, and sequence feature types, allowing all types that implement these generic types to use these attributes.
Specifically, attribute factories were added for the annotatable, bio entity, and sequence feature types, allowing all types that implement these generic types to use these attributes.
Specifically, the resolver is now using the correct sequence feature interface.
Co-authored-by: Sam Hokin <shokin@ncgr.org>
Co-authored-by: Sam Hokin <shokin@ncgr.org>
Co-authored-by: Sam Hokin <shokin@ncgr.org>
Co-authored-by: Sam Hokin <shokin@ncgr.org>
Co-authored-by: Sam Hokin <shokin@ncgr.org>
Specifically, the name was changed from hasGeneticMarkerFactory to hasGeneticMarkersFactory.
This includes introducing a HasGWAS interface to homogenize the gwas field across types. Similarly, a hasGWASFactory resolver was added to encapsulate the code that gets GWAS from the API.
This includes introducing a HasGWASResults interface to homogenize the gwasResults field across types. Similarly, a hasGWASResultsFactory resolver was added to encapsulate the code that gets GWASResults from the API.
This includes introducing a intermineGeneSortFactory for consistent sorting across gene models.
This includes introducing a HasLinkageGroup interface to homogenize the linkageGroup field across types. Similarly, a hasLinkageGroupFactory resolver was added to encapsulate the code that gets LinkageGroup from the API.
Updated MRNA to use these attributes.
This includes introducing a HasOntology interface to homogenize the ontology field across types. Similarly, a hasOntologyFactory resolver was added to encapsulate the code that gets Ontology from the API.
This includes introducing a HasOntologyRelations interface to homogenize the ontology field across types. Similarly, a hasOntologyRelationsFactory resolver was added to encapsulate the code that gets OntologyRelations from the API.
This interface is implemented by OntologyTerm and SOTerm. Corresponding generic model and resolver factories were implemented that are also used by OntologyTerm and SOTerm.
Updated OntologyTerm and SequenceOntologyTerm to use these attributes.
Updated OntologyTerm and SequenceOntologyTerm to use these attributes.
This includes introducing a HasOrganism interface to homogenize the organism field across types. Similarly, a hasOrganismFactory resolver was added to encapsulate the code that gets Organism from the API.
This includes introducing a HasPanGeneSets interface to homogenize the panGeneSets field across types. Similarly, a hasPanGeneSetsFactory resolver was added to encapsulate the code that gets PanGeneSet from the API.
This includes introducing a HasPhylotree interface to homogenize the phylotree field across types. Similarly, a hasPhylotreeFactory resolver was added to encapsulate the code that gets Phylotree from the API.
This includes introducing a HasProteinDomain interface to homogenize the proteinDomain field across types. Similarly, a hasProteinDomainFactory resolver was added to encapsulate the code that gets ProteinDomain from the API.
This includes introducing HasProtein and HasProteins interfaces to homogenize the protein and proteins fields, respectively, across types. Similarly, hasProteinFactory and hasProteinsFactory resolvers were added to encapsulate the code that gets PanGeneSets from the API.
This homogenizes the dataSet field across types. Similarly, a hasDataSetFactory resolver was added to encapsulate the code that gets DataSet from the API.
This includes introducing a HasQTLs interface to homogenize the qtls field across types. Similarly, a hasQTLsFactory resolver was added to encapsulate the code that gets QTLs from the API.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Unlike the 5.1.0.4 model changes PR, this PR will ultimately be merged. I'm opening it now as a draft to keep track of specific changes that will need to be scrutinized during the review.
Specific changes:
getPublicationsForDataSourceimplemented correctly? See commit b4a9d6d482b76651d5f58b40ca28104980b9c20egetIntronsForGenesimplemented correctly? See commit f4149304c52e6fa87e8b2d9b19ac3360d7110d44