It was already allowed in `test/functional/tools/sample_datatypes_conf.xml`
This will stop the skipping of tests requiring the `velvet` datatype, like
`ToolsUploadTestCase.test_composite_datatype` in
`test/api/test_tools_upload.py` .
We handle other bam types this way and other more specific variants of an extension (e.g. thermo.raw) so this feels like the more consistent thing to do.
The queryname sorted datatype (BamQuerynameSorted) ensures that the file is
queryname ordered. The BamInputSorted datatype can be used to describe the
output of aligners, which usually keep mate pairs adjacent. The BamInputSorted
datatype allows using tools that require mates to be adjacent, without
requiring an explicit sorting step. This can reduce the time and space
required for duplicate marking tools, HiC tools and structural variant
detection tools that require mates to be grouped together in an alignment file.
The BamQuerynameSorted has a converter that works for all datatypes that can be
consumed by samtools. There is no converter for BamInputSorted, since
BamQuerynameSorted is valid input for tools requiring BamInputSorted
input.
I'm targeting 18.01 since I think it would be very unfortunate if we start
annotating aligners with the very loose BamNative datatype, since this datatype
does not make any promises about sort order at all.
This closes https://github.com/galaxyproject/galaxy/issues/5497, goes
a long way towards the problems mentioned in https://github.com/galaxyproject/galaxy/issues/5496
and would make https://github.com/galaxyproject/tools-iuc/pull/1732 and https://github.com/galaxyproject/tools-iuc/pull/1591 better
This has been super helpful in debugging the SQL generated by Galaxy for recent PRs.
To use this simply enable the middleware, use your browser's network logger to find the URL of interest, copy the URL into the browser address bar and add ``?debug_sql=1`` to it. You will then see the sql in the logs only for that request and for every statement in that request.
Simply turning all logging on results in a deluge of logging I've never been able to grok and that is very hard to ping to particular request. Slow request logging is great but it doesn't make this kind of per-query full profile of the SQL generated as easy as this approach and isn't great at debugging performance problems when the result from a large number of small requests (you'd have to set a very low threshold to make sure you are logging every query and then it is no different from the full log).
Mehmet Tekman