Update README for performing DB migrations, add new indexes, update migration params #286
Conversation
…ex queries, update migration params
There was a problem hiding this comment.
Pull Request Overview
This PR updates the database migration process by adding new indexes, updating migration parameters in the migration environment, and providing updated documentation in the README on how to create and manage migrations.
- Introduces a migration script to manually create and drop new indexes.
- Adds an auto-generated migration that drops indexes using batch operations.
- Updates the migration environment configuration and enriches the README with detailed migration instructions.
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| migrations/versions/cdcadbe08ab3_manually_update_indexes.py | Adds manual index creation & removal migration script |
| migrations/versions/7be9deabf3ab_.py | Auto-generated migration for dropping indexes via batch operations |
| migrations/env.py | Updates Alembic configuration with custom include_object function |
| README.md | Adds documentation about creating and applying database migrations |
Comments suppressed due to low confidence (1)
migrations/versions/7be9deabf3ab_.py:1
- The migration file's docstring 'empty message' is unclear; please update it to provide a descriptive message about the migration's purpose.
"""empty message
| created_reason: Mapped[str] = mapped_column(db.Unicode(1024), nullable=False, default="", server_default="") | ||
|
|
||
| __table_args__ = ( | ||
| db.Index("idx_okta_user_group_member_user_id", "user_id"), |
There was a problem hiding this comment.
Huh, I thought Foreign Keys were automatically indexed, but looking further I guess not?
https://stackoverflow.com/a/970605
A foreign key must reference columns that either are a primary key or form a unique constraint, or are columns from a non-partial unique index. This means that the referenced columns always have an index to allow efficient lookups on whether a referencing row has a match. Since a DELETE of a row from the referenced table or an UPDATE of a referenced column will require a scan of the referencing table for rows matching the old value, it is often a good idea to index the referencing columns too. Because this is not always needed, and there are many choices available on how to index, the declaration of a foreign key constraint does not automatically create an index on the referencing columns.
https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-FK
Good find!
No description provided.