Closed alancleary closed 1 year ago
That would be a Very Good Thing. Unfortunately, the only place that the mine knows its own version is via a parameter that I throw into web.properties, which can be queried via a server-side Java class (not written). That's about the only place where random parameters are placed. I can write a servlet that returns a JSON that contains the mine properties, and then add a GraphQL type to hold that stuff. (There is also the mine.properties file that is used to build the mine, which is what shows the version at the very top of the mine web page. But that is not reachable after the build, it contains DB passwords and stuff. Which is why you have to double-enter it into the web.properties file.)
Hmm. That sounds like a bit of work. Perhaps we should wait until someone actually gets bit by it. It's probably a less likely than with GCV since people should just be pointing their GraphQL server at an existing InterMine instead of running one locally. I'll close the issue but feel free to reopen it if you decide to implement it.
It's not as bad as it sounds. Like a couple hours. I write Java code for the mines daily for pay. :)
Reopening since support for this will be added as part of legumeinfo/mine-issues#94.
Well, turns out good ol' Julie Sullivan already wrote the WebPropertiesServlet
which runs WebPropertiesService
. It reports the proper mine version from the mine.properties file! (And does not report passwords.) The mine version is web-properties.project.releaseVersion
. I'll put all the web-properties.project
items into a GraphQL type.
$ curl http://localhost:8080/minimine/service/web-properties/
{
"web-properties": {
"genomicRegionSearch": {
"enableStrandSpecificSearch": "true",
"exportChromosomeSegment": "true",
"howTo": "<ul><li>Genome regions in the following formats are accepted:<ul><li><b>chromosome:start..end</b>, e.g. <i>medtr.A17_HM341.gnm4.chr7:7148337..7149056</i></li><li><b>chromosome:start-end</b>, e.g. <i>medtr.A17_HM341.gnm4.chr7:7148337-7149056</i></li><li><b>tab delimited</b></li></ul><li>Both <b>base coordinate</b> (e.g. BLAST, GFF/GFF3) and <b>interbase coordinate</b> (e.g. UCSC BED, Chado) systems are supported, users need to explicitely select one. By default, the base coordinate is selected.</li><li>Each genome region needs to take a <b>new line</b>.</li></ul>",
"query": {
"Gene": {
"sortOrder": "{0}.chromosomeLocation.start asc",
"views": "{0}.primaryIdentifier,{0}.symbol,{0}.chromosomeLocation.locatedOn.primaryIdentifier,{0}.chromosomeLocation.start,{0}.chromosomeLocation.end,{0}.organism.shortName"
}
},
"display": "true",
"optionsCss": "",
"caption": "Search for features that overlap a list of genome coordinates you enter or upload, e.g. <b>medtr.A17_HM341.gnm4.chr7:7148337..7149056</b>",
"featureTypesExcluded": {
"global": "Supercontig, TRIMRetrotransposon, FivePrimeUTR, NcRNA, tRNA, NonLTRRetrotransposon, TargetSiteDuplication, GeneFlankingRegion, PreMiRNA, TerminalInvertedRepeat, Helitron, Primer Binding Site, TerminalInvertedRepeatElement, IntergenicRegion, ProteinMatch, ThreePrimeUTR, InvertedRepeat, TransposableElementGene, LTRRetrotransposon, RRTract, LongTerminalRepeat, RepeatRegion, PrimerBindingSite",
"byOrganism": ""
},
"defaultOrganisms": "M. truncatula",
"resultsJavascript": "",
"service": "",
"optionsJavascript": "",
"resultsCss": "",
"defaultSpans": "medtr.A17_HM341.gnm4.chr1:100000-200000\\nmedtr.A17_HM341.gnm4.chr2:100000-200000\\nmedtr.A17_HM341.gnm4.chr3:100000-200000",
"liftOver": {
"default": "false",
"url": ""
},
"jbrowse": {
"install": {
"url": "https://mines.legumeinfo.org/jbrowse"
},
"3880": "Medicago_truncatula",
"display": "false",
"url": "https://mines.legumeinfo.org/jbrowse"
}
},
"quickSearch": {
"identifiers": "Medtr7g005530, zinc finger protein"
},
"bag": {
"results": {
"table": {
"size": "5"
}
},
"example": {
"identifiers": "Medtr4g113520,Medtr4g104230,Medtr7g022250"
}
},
"project": {
"subTitle": "A small variety of genomes and annotations to aid code development.",
"citation": "<a href=\"http://www.ncbi.nlm.nih.gov/pubmed/23023984\" target=\"_blank\">Smith RN, et al. InterMine: a flexible data warehouse system for the integration and analysis of heterogeneous biological data. Bioinformatics. 2012 Dec 1;28(23):3163-5.</a>",
"releaseVersion": "5.1.0.1",
"standalone": "true",
"helpLocation": "https://dev.lis.ncgr.org/minimine/help",
"title": "MiniMine",
"sitePrefix": "https://dev.lis.ncgr.org/minimine"
},
"bluegenes": {
},
"services": {
},
"list": {
"input": {
"example": "New list name"
},
"upload": {
"delimiters": ","
}
},
"oauth2_providers": []
}
}
PR #14 provides a type containing the project data, including releaseVersion
. I'm not sure what to do from there to ensure that the GraphQL model version matches the mine version, I'll leave that to you.
I'm going to go ahead and implement this. I think I'll have it log an error but not crash the server if the Intermine version is older than what the GraphQL data source requires since in that case most of the data source should still be functional. Additionally, this approach means we don't have to lockstep our Intermine and GraphQL updates.
I just discovered that the mineWebProperties query is not resolving. The mine URL is fine and returns the data, so it's in the graphql resolution somewhere. Let me know if you'd like me to track it down, I expect it's trivial.
curl https://mines.legumeinfo.org/phaseolusmine/service/web-properties?format=json
I just discovered that the mineWebProperties query is not resolving. The mine URL is fine and returns the data, so it's in the graphql resolution somewhere. Let me know if you'd like me to track it down, I expect it's trivial.
curl https://mines.legumeinfo.org/phaseolusmine/service/web-properties?format=json
Can you provide more details so I can replicate the issue? I've been using the webProperties
method in the IntermineServer
class without issue.
From graphql server log:
https://mines.legumeinfo.org/phaseolusmine/service/web-properties?format=json
which works fine:
$ curl "https://mines.legumeinfo.org/phaseolusmine/service/web-properties?format=json"
{"web-properties":
{"genomicRegionSearch":{"enableStrandSpecificSearch":"true","exportChromosomeSegment":"true","howTo":"<ul><li>Genome regions in the following formats are accepted:<ul><li><b>chromosome:start..end<\/b>, e.g. <i>phavu.G19833.gnm1.Chr02:3867113..3870724<\/i><\/li><li><b>chromosome:start-end<\/b>, e.g. <i>phavu.G19833.gnm1.Chr02:3867113-3870724<\/i><\/li><li><b>tab delimited<\/b><\/li><\/ul><li>Both <b>base coordinate<\/b> (e.g. BLAST, GFF/GFF3) and <b>interbase coordinate<\/b> (e.g. UCSC BED, Chado) systems are supported, users need to explicitely select one. By default, the base coordinate is selected.<\/li><li>Each genome region needs to take a <b>new line<\/b>.<\/li><\/ul>","query":{"Gene":{"sortOrder":"{0}.chromosomeLocation.start asc","views":"{0}.primaryIdentifier,{0}.symbol,{0}.chromosomeLocation.locatedOn.primaryIdentifier,{0}.chromosomeLocation.start,{0}.chromosomeLocation.end,{0}.organism.shortName"}},"display":"true","optionsCss":"","caption":"Search for features that overlap a list of genome coordinates you enter or upload, e.g. <b>phavu.G19833.gnm1.Chr02:3867113-3870724<\/b>","featureTypesExcluded":{"global":"","byOrganism":""},"defaultOrganisms":"P. vulgaris","resultsJavascript":"","service":"","optionsJavascript":"","resultsCss":"","defaultSpans":"phavu.G19833.gnm1.Chr01:100000..200000\\nphavu.G19833.gnm1.Chr02:100000..200000\\nphavu.G19833.gnm1.Chr03:100000..200000","liftOver":{"default":"false","url":""},"jbrowse":{"install":{"url":"https://mines.legumeinfo.org/jbrowse"},"display":"false","3885":"Phaseolus_vulgaris","url":"https://mines.legumeinfo.org/jbrowse"}},"quickSearch":{"identifiers":"e.g Phvul.002G040500"},"bag":{"results":{"table":{"size":"5"}},"example":{"identifiers":"Phvul.002G040500"}},"project":{"subTitle":"Phaseolus species data from the Legume Information System","citation":"<a href=\"http://www.ncbi.nlm.nih.gov/pubmed/23023984\" target=\"_blank\">Smith RN, et al. InterMine: a flexible data warehouse system for the integration and analysis of heterogeneous biological data. Bioinformatics. 2012 Dec 1;28(23):3163-5.<\/a>","releaseVersion":"5.1.0.2","standalone":"true","helpLocation":"https://mines.legumeinfo.org/phaseolusmine/help","title":"PhaseolusMine","sitePrefix":"https://mines.legumeinfo.org/phaseolusmine"},"bluegenes":{},"services":{},"list":{"input":{"example":"New list name"},"upload":{"delimiters":","}},"oauth2_providers":[]}
,"executionTime":"2023.07.24 09:56::37","wasSuccessful":true,"error":null,"statusCode":200}
But the graphql query returns null:
$ curl --request POST \
--header 'content-type: application/json' \
--url http://localhost:4444/ \
--data '{"query":"query Query {\n mineWebProperties {\n results {\n subTitle\n citation\n releaseVersion\n standalone\n helpLocation\n title\n sitePrefix\n }\n }\n}","variables":{}}'
{"data":{"mineWebProperties":{"results":null}}}
Forget that deleted comment, was just a connectivity burp. I'm just getting null back from the query as shown above, no error. True for main branch as well as configurable-uris.
I can track it down, but I'm mystified that it's not reproduced on your end.
@sammyjava I see the issue. I'm using the info internally to verify that the intermine data source is compatible with the mine at the URI it's initialized with; no GraphQL queries are involved in this. Whereas you're getting the web properties via the GraphQL API, which I haven't tested at all. In fact, I think the WebProperties query should be removed from the GraphQL API since the mine is an implementation detail and the query will become ambiguous when we tackle issue #18.
Sounds sensible. I'll yank it.
Done in PR #68.
@sammyjava Does an InterMine instance know its version? And, if so, do you think it would be worth pinning what version of InterMine the
IntermineAPI
class is compatible with so the class can check it's compatible when it's first instantiated? I started doing this with the GCV microservices because people (including myself) were forgetting to upgrade and I was wasting time "debugging".