Fix double CREATE TYPE for workspace_role enum#13
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Alembic migration ChangesMigration Simplification
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This fixes the double
CREATE TYPE workspace_role AS ENUM...statement that ran once in the standalone statement and again in the column definition despitecreate_type=Falsebecause SQL Alchemy ignores the argument when the definition contains the enum values.This also removes all the boilerplate for checking whether objects exist—these are inappropriate for migrations which should hard-fail when the DB state does not match the encoded definitions. Those checks masked the issue in some situations.
Summary
This PR simplifies the Alembic migration for the user role table by removing idempotency checks and directly applying schema changes without bind-time introspection.
Changes Made
File:
alembic_osm/versions/9221408912dd_add_user_role_table.pytextfromsqlalchemyfor executing raw SQLupgrade()function: Unconditionally creates theauth_uid_uniqueunique constraint and theuser_workspace_rolestable with:sa.Enum("lead", "validator", "contributor", name="workspace_role"))downgrade()function: Unconditionally drops the table, executes rawDROP TYPE workspace_roleSQL, and drops the constraintImpact
The migration now follows a stricter pattern appropriate for database versioning: directly applying changes rather than checking for object existence before creation. This eliminates the double enum creation issue that occurred when existence checks masked the problem. The migration will hard-fail if the database state does not match the encoded definitions, which is the expected behavior for schema migrations.
Lines changed: +16/-63