feat(search): FTS + trigram GIN indexes for global search#15220
Open
blakeaowens wants to merge 3 commits into
Open
feat(search): FTS + trigram GIN indexes for global search#15220blakeaowens wants to merge 3 commits into
blakeaowens wants to merge 3 commits into
Conversation
Adds a weighted tsvector GIN index and a gin_trgm_ops index on the short display column of the ten models the Pro global search queries (finding, product, product_type, engagement, test, endpoint, location, finding_template, app_analysis, vulnerability_id), plus the pg_trgm extension. The indexes are built from SearchVector/OpClass ORM objects so the index expression tracks the query's compiled SQL across Django upgrades, and are database-only (SeparateDatabaseAndState with no state operations) since they are search-performance indexes, not part of any model's public schema. atomic=False because CONCURRENTLY / CREATE EXTENSION cannot run in a transaction. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
github-actions
Bot
added
the
New Migration
The 0278 trigram GIN indexes used a django.contrib.postgres OpClass
expression, which renders to invalid SQL ("syntax error at or near
gin_trgm_ops") unless django.contrib.postgres is in INSTALLED_APPS, and it
is not in the OSS standalone settings. Switch to the base Index opclasses
option, which renders the identical `USING gin (col gin_trgm_ops)` SQL
without requiring that app. The tsvector indexes are unaffected
(SearchVector renders without the app).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move the global-search GIN indexes from a database-only migration into each model's Meta.indexes (house style, matching the other functional-index migrations), and register django.contrib.postgres in INSTALLED_APPS so the SearchVector index expressions and trigram lookups are supported. 0278 becomes a plain AddIndexConcurrently migration matching model state. Indexes: weighted tsvector FTS + gin_trgm_ops trigram on finding, product, product_type, engagement, test, endpoint, location, finding_template, app_analysis, vulnerability_id. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
github-actions
Bot
added
the
settings_changes
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds the Postgres full-text-search and fuzzy-match GIN indexes that DefectDojo Pro's new global search relies on, so the index scaffolding lives in OSS (built from the ORM) rather than in a Pro-side raw-SQL migration.
What it adds (
0278_global_search_fts_trigram_indexes)pg_trgmextension (TrigramExtension).tsvectorGIN index (title/nameweight A,descriptionweight B) on each of the ten searchable models: finding, product, product_type, engagement, test, endpoint, location, finding_template, app_analysis, vulnerability_id.gin_trgm_opsindex on each model's short display column for word-similarity (%>/__trigram_word_similar) fuzzy matching.Why this shape
SearchVector/OpClassORM objects, not raw SQL, so the index expression tracks the query's compiled SQL across Django upgrades and can't silently drift into a sequential scan.SeparateDatabaseAndStatewith no state operations): these are pure search-performance indexes, not part of any model's public schema, so they stay out of every model'sMeta.indexes.makemigrations --checkstays clean.atomic = FalsebecauseCREATE INDEX CONCURRENTLY/CREATE EXTENSIONcannot run inside a transaction.