Basically search.py was assuming certain class attributes are available that are not available until after mapping.init has done its thing. This delays evaluation of those class attributes until runtime.
create_db and manage_db should now work with install as well.
Migrations are symbolic links into lib/galaxy/model/migrate/versions of migrations affecting these tables. All future migrations to these tables should created in one place like this and linked in the other.
Now app.model and app.install_model may be two distinct objects not just two references to the same object. Add ModelMapping class for galaxy.model.tool_shed_install.
If install_database_connection is set in Galaxy configuration, a separate database will be targetted for the persistence of the tool shed repository information. Additional database options may likewise be specified in this case: install_database_engine_option_pool_size, etc....
All references to galaxy.model.tool_shed_install models should go through this instance. Right now it is a reference to the same ModelMapping instance, but the goal is to allow them to be two different mappings.
Specifically, refactor all tool shed installation related models and mapping information in Galaxy's models into new module galaxy.model.tool_shed_install.
This is work toward being able to store tool shed installation data into a second database. There is still a lot TODO, all access to these models are still through galaxy.model and the existing ModelMapping object, these references need to be refactored.
More information on the end goal here: http://dev.list.galaxyproject.org/Galaxy-less-Tool-Installing-tp4660655.html.
Shared across Tool Shed and Galaxy to reduce code duplication. Previously this was just a bunch, making it a real class allows placing some shared logic in there.
This refactoring also eliminates some global variables galaxy.model.mapping.Session, galaxy.model.mapping.context, and same for tool shed. This may break things, but these are things that should probably be fixed anyway.
In particular small changes to db_shell.py and a unit test that depended on these global variables have been updated. The functional test frameworks likewise needed to be updated to not depend on these - these changes were more substantial.
To fix these functional tests, I essentially replace old references to global variables in Galaxy with references to global variables just defined in the test framework in test/functional/database_contexts.py (a slight improvement).
Namely create_db.py,db_shell.py, and manage_db.py.
Move duplicated code into lib/galaxy/model/orm/scripts.py - add unit tests. PEP-8 clean up of all 4 files. Add incoherent incoherent comment at top of manage_db.py.
As a result of the code de-duplication create_db.py should be usable with the tool shed now.
Will be refactoring lib/galaxy/model/orm/scripts.py to work with new tool shed install database - it will be good to have a place to test these and allow manage_db.py and clean_db.py to work immediately.
Basically adds __init__.py files to each subdirectory so nose detects these as Python module directories. Also modify dynamic loading of modules in Carl's test cases so the test case can be run with any cwd - including the Galaxy root directory as run_unit_tests.sh will use.
This should roughly double the number of unit tests buildbot runs.
Looks to have been replaced by method with same name in install_and_test_tool_shed_repositories/functional_tests.py and would throw a NameError on repository_id if ever used.
Dave Bouvier