Usually tests should have new histories but we should still capture this information so we can target tests are particular histories for debugging interactively and so we could potentially reduce the number of new histories created when testing remote Galaxies (there have been complaints about this in the past).
This seems to be necessary so that the workflow_stability test passes
under python 2 and python3, but does change the result under python 2,
hence the updated workflows (produced by uploading and downloading the
workflow to an instance running with this commit).
This is good for a few reasons
* It speeds up the bottleneck that is the job creation code in the web thread (the job handler is much easier to parallelize). Skipping the flush for all those datasets and skipping the disk write per dataset should really speed things up nicely when submitting large numbers of jobs and jobs with a large number of inputs.
* This prevents a disk slow down from grinding the web response to a halt. We don't want the handler to freeze up either - but if something is going to freeze it is a better user experience and easier to recover from the job handler freezing while their are disk problems.
* This allows per-job-handler object store configurations - simply configure different job handlers with different object store configurations. This is cool and important and I can imagine some awesome applications but I will wait for them to materialize.
- Test hierarchical store uses its first disk store for new files and not the remaining entries.
- Test basic functionality of writing to the distributed object store.
- Test all job outputs get placed in the same object store.
- Switch select_tag to group_tag as a parameter name - since it is restricted to group_tags and we don't call data parameters select_data.
- Add minimal XSD documentation for this new parameter type.
- Add example tools - for single and multiple tags.
- Add API tests for these tools and the tag handling.
When creating thousands of jobs for large database transactions - previously Galaxy would query the database thousands of times for the same history id, user id, and session id.
Unlike upload 1.0, use different 'src' types to distinguish between URLs and pasted content - in the abstract this is better because it is more structured and practically this allows 'pasting' spreadsheets that start with URLs for instance (that is sometimes useful).