of downloading its own SGE and linking, scramble now just links to a
user-supplied SGE in $SGE_ROOT.
Added a seperate script to make it build right on sparc/x86 32/64
Solaris.
If a dataset is not the proper format required by a tool, but there is a converter available, the dataset will appear as a valid option in DataToolParameters.
The converted dataset will be created (and subsequently reused) when the job is executed. Conversion utilizes the job runner, and will run on the cluster.
Setting metadata will invalidate the converted dataset, and a new one will be automatically generated as needed.
Whether running locally or via PBS, $PATH should now be handled in your
user's environment.
This also fixes problems like PYTHONPATH on the new blast nodes being
wrong (because they are x86_64 and the frontends are i686).
Note that you can actually start Galaxy without having an eggs dir now.
- Added an option to remove dataset from disk when purging, or leave them for renaming and later removal
- Moved History.purge() and Dataset.purge() methods to the cleanup_datasets.py script
- Eliminated duplicate functionality from admin controller, moving appropriate components to Galaxy reports.
- Re-implemented the long-term process we will use for deleting / purging histories and datasets
(we will initially write external shell scripts to rename dataset files rather then deleting them)
distribution point and copy them to Galaxy's eggs/ directory.
fetch_eggs_tarball.py and check_python_platform.py are mostly for offline
systems. fetch_eggs_tarball.py fetches eggs for your platform (or a
specified platform) and then tars them up, for copying to another system.
check_python_platform.py returns the string for your platform/interpreter
that will be used to download from the egg distribution site.
For those that may have installed revision 2256, use the following SQL command to evolve your schema:
alter table dataset drop column removed;
We have changed direction again on the process we will use to cleanup datasets and histories.
- When we are comfortable with the purge process, the Dataset.purge() function will be modified to delete the file from disk rather than simply renaming it, and the Dataset.remove_from_disk() function will be eliminated.
- The entire process below must be executed at least 1 time ( prior to making these changes ) to ensure that purged files are properly removed from disk. This process is:
delete_userless_histories() -> purge_histories() -> purge_datasets() -> remove_datasets()
Shell scripts have been added for each of these stages with the exception of remove_datasets(), which will eventually be eliminated.
SQL commands to alter schema:
alter table dataset add column removed boolean default 'f';
alter history add column purged boolean default 'f';
- The lifecycle of a history after creation is now deleted -> purged
- Deleting a history will delete all associated datasets (only the database is update, nothing removed from disk).
- Purging a history will purge all associated datasets (datasets are renamed, nothing removed from disk).
- The lifecycle of a dataset after creation is now deleted -> purged -> removed
- Deleting a dataset will only update the database.
- Purging a dataset will rename the file on disk and update the database.
- Removing a dataset will remove the renamed, purged file from disk and update the database.
- Also reverted the behavior of history_delete() to pre-rev 2250 so that no datasets are deleted at teh time the history was deleted by the user.
- The admin controller and the cleanup_datasets.py script include all of the above functionality.
Nate Coraor