For all four grid types (histories, viz, workflows, and pages), this computes rating average on the server and prefetches any annotations. This eliminates at least two extra queries for response element in the grid. See comment in the history controller for why I am fairly confident this is a good idea for annotations but tags are less obvious - these grids still go back to the postgres server multiple times per rendered item to render tags.
I'm confident we should either subqueryload, joinedload, or upgrade to sqlalchemy 2.2 and selectinload (http://docs.sqlalchemy.org/en/latest/orm/loading_relationships.html#sqlalchemy.orm.selectinload) the tags as well - but I'm not sure which without being able to hack on a usegalaxy.org.
This also brings in less of the user model (only username instead of all of it) to reduce over-the-wire transmission of unneeded data from postgres to Galaxy.
For workflows we were LEFT OUTER JOIN-ing on the steps of the latest workflow - so we were bringing back a lot of extra rows for data that was completely unused. In light of this, it makes perfect sense to me why published workflows were the slowest of these and I suspect they will all be equally performant after this change (modulo the number of rows in the tables and the number of rows rendered).
Don't LEFT OUTER JOIN workflow against its steps to produce step count - this causes a lot of duplicated workflow data and fetches step data not needed to just produce a step count.
Tweak pre-fetching for workflows shared with user also.
Backend was enhanced to allow this in #5196 and a new entry point to setting exit code for such exit conditions but the custom parsing wasn't updated to allow it. Thanks to @nsoranzo for the catch.
Still dealing with fallout from 78babab645. After that commit we were treating structured_like collections like collections with unknown structure and not dealing with collection_type_source information at all when building backbones for new collections during mapping.
Delete button now a drop down menu (like dropdown for downloading metadata files).
- Top option just deletes the collection.
- Second option deletes the collection and attempts to delete the datasets contained within it.
- The third option deletes the collection and attempts to purge the datasets within it.
- Nametags weren't being picked up on collection inputs - so for instance tools that take in a single collection and produce a dataset or file weren't propagating nametags (unless the collection contents had tags). To see this create two unnamed datasets without tags, create a pair from them, add a tag to the pair, and run the pair through the "paired_test" test tool.
- Nametags weren't being propagated to the outputs of collection operations.
Without this change, uploading non-metadata changes to a toolshed repository will display an error message and create a new metadata revision regardless of whether the code should determine that a new metadata revision is warranted.
This would affect for example the mapping over of fastq-dump (and all other
tools in the sra-toolkit).
If one had attempted this previously the discovery phase would fail with:
```
galaxy.tools.parameters.output_collect ERROR 2018-01-30 08:56:46,369 Problem gathering output collection.
Traceback (most recent call last):
File "/bioinfo/guests/mvandenb/galaxy/lib/galaxy/tools/parameters/output_collect.py", line 169, in collect_dynamic_collections
collection
File "/bioinfo/guests/mvandenb/galaxy/lib/galaxy/managers/collections.py", line 216, in collection_builder_for
return builder.BoundCollectionBuilder(dataset_collection, collection_type_description)
File "/bioinfo/guests/mvandenb/galaxy/lib/galaxy/dataset_collections/builder.py", line 84, in __init__
raise Exception("Cannot reset elements of an already populated dataset collection.")
Exception: Cannot reset elements of an already populated dataset collection.
```
Instead we force the collection state to be new when we are discovering output collection datasets,
which seems reasonable to me. This includes an API testcase that would have failed previously.
Conda 4.3.33 contains a fix that should solve some conda env
creation programs:
https://github.com/conda/conda/pull/6766
Also support conda installation on x86 Linux architecture.
mvdbeek