Skip to main content
galaxy-db-migration Galaxy database migration with Alembic - create schema changes (add table/column), upgrade/downgrade database versions, check migration status, troubleshoot errors. Use for: SQLAlchemy model changes, database schema modifications, Alembic revisions, migration version conflicts, lib/galaxy/model changes.
Zur Installation springen Skills Marktplatz Entdecken und erkunden Sie KI-Skills, die von der Community erstellt wurden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Prompt kopierenPrompt-Details anzeigen Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
npx skills add https://github.com/arash77/galaxy-claude-marketplace --skill galaxy-db-migrationDer Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.
Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.
ZIP herunterladen Herunterladen... Mehr aus diesem Repository Galaxy project development conventions and skill routing guide. ALWAYS load this skill when working in a Galaxy codebase. Routes to appropriate skills: use /galaxy-db-migration for database/Alembic/schema changes, /galaxy-api-endpoint for creating REST API endpoints/FastAPI routers, /galaxy-testing for running or writing tests, /galaxy-linting for code formatting/linting/type checking. Use galaxy-explorer agent for codebase architecture questions.
Galaxy code linting, formatting, and type checking. Run checks, auto-fix formatting, Python lint, client lint, mypy type checks. Use for: ruff, flake8, black, isort, darker, autoflake, pyupgrade, eslint, prettier, mypy, tox, make format, make diff-format, code style, lint failures, CI lint checks, formatting errors, type errors, codespell, redocly, api schema, xsd, config lint.
Create Galaxy REST API endpoints with FastAPI routers, Pydantic schemas, and manager pattern. Use for: new API routes, FastAPI endpoints, REST resources, Pydantic request/response models, lib/galaxy/webapps/galaxy/api routers, lib/galaxy/schema definitions, API controller creation.
Verwandte Berufe SOC
Basierend auf der SOC-Berufsklassifikation
name galaxy-db-migration description Galaxy database migration with Alembic - create schema changes (add table/column), upgrade/downgrade database versions, check migration status, troubleshoot errors. Use for: SQLAlchemy model changes, database schema modifications, Alembic revisions, migration version conflicts, lib/galaxy/model changes.
argument-hint [create|upgrade|downgrade|status|troubleshoot]
Persona: You are a senior Galaxy database developer working with Alembic migrations.
Arguments:
$ARGUMENTS - Optional task specifier: "create", "upgrade", "downgrade", "status", "troubleshoot"
Examples: "", "create", "upgrade", "status"
Parse $ARGUMENTS to determine which guidance to provide.
Quick Reference: Galaxy Database Migrations
Galaxy uses Alembic for database schema migrations with two branches :
gxy - Galaxy model (main application database) - lib/galaxy/model/migrations/alembic/versions_gxy/
tsi - Tool shed install model (rarely used) - lib/galaxy/model/migrations/alembic/versions_tsi/
Three Scripts Available
manage_db.sh - Admin script for production (upgrade, downgrade, init)
scripts/db_dev.sh - Dev script with full Alembic features (includes revision command)
scripts/run_alembic.sh - Advanced wrapper for direct Alembic CLI access
If $ARGUMENTS is empty: Display Task Menu
Present this menu to the user:
create - Create a new migration revision
upgrade - Upgrade database to latest version
downgrade - Downgrade database to previous version
status - Check current database version vs codebase
troubleshoot - Diagnose migration errors
./scripts/db_dev.sh dbversion - Show current DB version
./scripts/db_dev.sh version - Show head revision in codebase
./scripts/db_dev.sh history --indicate-current - Show migration history with current position
If $ARGUMENTS is "create": Guide Through Creating Migration
Step 1: Update the Model Ask the user if they have:
Updated SQLAlchemy models in lib/galaxy/model/__init__.py
Added tests to test/unit/data/model/mapping/test_*model_mapping.py
If not, remind them these are prerequisites before creating a migration.
Step 2: Create Revision File ./scripts/db_dev.sh revision -m "brief_description_of_change"
This creates a new file in lib/galaxy/model/migrations/alembic/versions_gxy/ with format:
<revision_id>_<message>.py
Step 3: Fill Out Migration Open the newly created file. You'll need to implement:
import sqlalchemy as sa
from galaxy.model.custom_types import JSONType, TrimmedString
from galaxy.model.migrations.util import (
create_table, drop_table,
add_column, drop_column, alter_column,
create_index, drop_index,
create_foreign_key, create_unique_constraint, drop_constraint,
table_exists, column_exists, index_exists,
transaction,
)
Available utility functions:
create_table(table_name, *columns) - Create new table
drop_table(table_name) - Drop table
add_column(table_name, column) - Add column
drop_column(table_name, column_name) - Drop column
alter_column(table_name, column_name, **kw) - Modify column
create_index(index_name, table_name, columns, **kw) - Create index
drop_index(index_name, table_name) - Drop index
create_foreign_key(constraint_name, table_name, columns, referent_table, referent_columns) - Create FK
create_unique_constraint(constraint_name, table_name, columns) - Create unique constraint
drop_constraint(constraint_name, table_name) - Drop constraint
transaction() - Context manager for transaction wrapping
Check functions (for conditional migrations):
table_exists(table_name, default) - Check if table exists
column_exists(table_name, column_name, default) - Check if column exists
index_exists(index_name, table_name, default) - Check if index exists
foreign_key_exists(constraint_name, table_name, default) - Check if FK exists
unique_constraint_exists(constraint_name, table_name, default) - Check if constraint exists
Implement upgrade() and downgrade():
def upgrade ():
with transaction():
pass
def downgrade ():
with transaction():
pass
Step 4: Review Example Suggest reading the most recent migration for reference:
ls -t lib/galaxy/model/migrations/alembic/versions_gxy/*.py | head -1
Then read it to see current patterns (e.g., 04cda22c48a9_add_job_direct_credentials_table.py).
Step 5: Run Migration
Step 6: Verify
Migration runs without errors
Database schema matches model
Tests pass: ./run_tests.sh -unit test/unit/data/model/mapping/test_*model_mapping.py
If $ARGUMENTS is "upgrade": Guide Through Upgrading Standard upgrade to latest:
This upgrades both gxy and tsi branches to head.
Upgrade to specific release:
./manage_db.sh upgrade 22.05
./manage_db.sh upgrade release_22.05
./scripts/run_alembic.sh upgrade gxy@head
Upgrade by relative steps:
./scripts/run_alembic.sh upgrade gxy@+1
Check status before upgrading:
./scripts/db_dev.sh dbversion
./scripts/db_dev.sh version
Always backup database before upgrading
Shut down all Galaxy processes during migration to avoid deadlocks
First-time Alembic upgrade: run without revision argument to initialize
If $ARGUMENTS is "downgrade": Guide Through Downgrading Downgrade by one revision:
./manage_db.sh downgrade <current_revision_id>-1
Downgrade to specific revision:
./manage_db.sh downgrade <revision_id>
Downgrade to specific release:
./manage_db.sh downgrade 22.01
./manage_db.sh downgrade release_22.01
Downgrade gxy branch only:
./scripts/run_alembic.sh downgrade gxy@-1
Downgrade to base (empty database):
./scripts/run_alembic.sh downgrade gxy@base
Check current position first:
./scripts/db_dev.sh history --indicate-current
Always backup database before downgrading
Oldest release: 22.01
Downgrading to 22.01 requires SQLAlchemy Migrate version 180
If $ARGUMENTS is "status": Show Status Commands Check current database version:
./scripts/db_dev.sh dbversion
Output shows current revision(s) with (head) marker if up-to-date.
Check head revision in codebase:
./scripts/db_dev.sh version
Shows latest revision IDs for both branches.
./scripts/db_dev.sh history --indicate-current
Shows chronological list with (current) and (head) markers.
Show specific revision details:
./scripts/db_dev.sh show <revision_id>
Compare database vs codebase:
If dbversion shows different revision than version, database needs upgrade/downgrade.
If $ARGUMENTS is "troubleshoot": Provide Troubleshooting Guidance
Problem: Deadlock detected Cause: Migration requires exclusive access to database objects while Galaxy is running.
Shut down all Galaxy processes (web servers, job handlers, workflow schedulers)
Run migration again
Restart Galaxy after successful migration
Problem: migrations.IncorrectVersionError Cause: Database not at expected SQLAlchemy Migrate version before Alembic upgrade.
Backup database
Check migrate_version table - should be version 180
If < 180: Checkout 22.01 branch, run old manage_db.sh upgrade
If = 181 (rare): Downgrade to 180 using old manage_db.sh
Switch back to current branch
Run ./manage_db.sh upgrade
Problem: Database version mismatch on startup Error: "Database is at revision X but codebase expects revision Y"
Check which is ahead:
./scripts/db_dev.sh dbversion
./scripts/db_dev.sh version
If database behind: ./manage_db.sh upgrade
If database ahead: Either upgrade codebase or downgrade database
Problem: Migration fails with "table already exists" Cause: Migration not idempotent or database in unexpected state.
Check if table/column already exists in database
Use check functions in migration:
from galaxy.model.migrations.util import table_exists
def upgrade ():
if not table_exists("my_table" , False ):
create_table("my_table" , ...)
Consider using --repair flag if implementing manual fixes
Problem: Cannot find revision file Cause: Migration file not in expected directory.
Ensure file is in lib/galaxy/model/migrations/alembic/versions_gxy/
Check file naming: <revision_id>_<message>.py
Verify imports and module structure
Problem: Foreign key constraint violation Cause: Migration tries to add FK but referential integrity violated.
Clean up orphaned rows before adding constraint
Add data migration in upgrade() before schema change
Use with transaction(): to ensure atomicity
Additional Resources
Models: lib/galaxy/model/__init__.py
Utilities: lib/galaxy/model/migrations/util.py
Tests: test/unit/data/model/mapping/test_*model_mapping.py
Recent examples: lib/galaxy/model/migrations/alembic/versions_gxy/ (check latest files)
Common patterns to follow:
Always wrap operations in with transaction():
Use Galaxy util functions instead of raw Alembic ops
Implement both upgrade() and downgrade()
Test migrations on dev database before committing
Use descriptive revision messages