Skip to content

Commit d59681b

Browse files
Maffoochclaude
andcommitted
docs(vuln-id): remove stale dual-write/flag comments (entity-only)
The compat fields and reconcile/copy paths still described the removed read-flag + dual-write architecture. Reword to the entity-only reality: VulnerabilityIdsField reads the entity references; copy()/reimport read through the entity helper and write through the entity seam; the unique_finding_order comment says "write path" not "dual-write". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1 parent d25dfec commit d59681b

4 files changed

Lines changed: 13 additions & 15 deletions

File tree

dojo/finding/api/serializer.py

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -309,10 +309,10 @@ class VulnerabilityIdsField(serializers.Field):
309309
"""
310310
Wire-frozen v2 vulnerability_ids field.
311311
312-
Reads ``[{"vulnerability_id": str}]`` from the flag-appropriate store (legacy rows or the
313-
entity references) — byte-identical either way because writes are dual. Accepts the same
314-
object list (tolerating bare strings) on write and hands the parsed strings to create/update
315-
under ``parsed_vulnerability_ids``, which funnel to save_vulnerability_ids (unchanged path).
312+
Reads ``[{"vulnerability_id": str}]`` from the finding's entity references (ordered,
313+
primary/cve first). Accepts the same object list (tolerating bare strings) on write and hands
314+
the parsed strings to create/update under ``parsed_vulnerability_ids``, which funnel to
315+
save_vulnerability_ids (unchanged path).
316316
"""
317317

318318
def __init__(self, **kwargs):
@@ -325,7 +325,7 @@ def get_attribute(self, instance):
325325
return instance
326326

327327
def to_representation(self, finding):
328-
from dojo.vulnerability.queries import finding_vulnerability_id_strings # noqa: PLC0415 -- flag seam
328+
from dojo.vulnerability.queries import finding_vulnerability_id_strings # noqa: PLC0415 -- avoid import cycle
329329
return [{"vulnerability_id": value} for value in finding_vulnerability_id_strings(finding)]
330330

331331
def to_internal_value(self, data):

dojo/finding/models.py

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -705,10 +705,9 @@ def copy(self, test=None):
705705
# Assign any tags
706706
copy.tags.set(old_tags)
707707
# Copy the vulnerability ids and CWEs (relation rows aren't copied by copy_model_util).
708-
# Route vulnerability ids through the dual-write seam so the copy gets legacy rows AND
709-
# entity references (copy.cve was already carried over by copy_model_util). Read the SOURCE
710-
# ids through the flag seam too (not the legacy relation directly), so copy() keeps working
711-
# after the legacy Vulnerability_Id store is retired.
708+
# Write the copy's ids through the entity write seam (copy.cve was already carried over by
709+
# copy_model_util), and read the SOURCE ids through the entity read helper (not a legacy
710+
# relation).
712711
from dojo.vulnerability.manager import persist_for_finding # noqa: PLC0415 -- avoid import cycle
713712
from dojo.vulnerability.queries import finding_vulnerability_id_strings # noqa: PLC0415
714713

dojo/importers/default_reimporter.py

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -988,10 +988,9 @@ def reconcile_vulnerability_ids(
988988
# while vulnerability_ids do not, and vice versa).
989989
self.reconcile_cwes(finding)
990990

991-
# Read the existing ids through the flag seam (entity references when the flag is on, legacy
992-
# rows when off) instead of the legacy relation directly, so reconcile keeps working after
993-
# the legacy Vulnerability_Id store is retired. The prefetch is seam-matched upstream (the
994-
# reimport finding query uses vulnerability_id_prefetch()), so this stays a no-query read.
991+
# Read the existing ids through the entity read helper (not a legacy relation). The prefetch
992+
# is matched upstream (the reimport finding query uses vulnerability_id_prefetch()), so this
993+
# stays a no-query read.
995994
from dojo.vulnerability.queries import finding_vulnerability_id_strings # noqa: PLC0415 -- avoid import cycle
996995

997996
existing_vuln_ids = set(finding_vulnerability_id_strings(finding))
@@ -1005,7 +1004,7 @@ def reconcile_vulnerability_ids(
10051004
)
10061005
return finding
10071006

1008-
# Accumulate delete + insert for batch flush (legacy rows + entity refs, dual-write).
1007+
# Accumulate delete + insert for batch flush (entity references).
10091008
self.vulnerability_id_manager.record_reconcile(finding, vulnerability_ids_to_process)
10101009
if vulnerability_ids_to_process:
10111010
finding.cve = vulnerability_ids_to_process[0]

dojo/vulnerability/models.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -77,7 +77,7 @@ class Meta:
7777
models.UniqueConstraint(fields=["finding", "vulnerability"], name="unique_finding_vulnerability"),
7878
# Structural guarantee of a single primary id per finding: no two references may share
7979
# an order (in particular, never two order-0 rows). Compatible with the delete-then-
80-
# insert dual-write, which assigns 0..n-1 in one transaction (see manager.py).
80+
# insert write path, which assigns 0..n-1 in one transaction (see manager.py).
8181
models.UniqueConstraint(fields=["finding", "order"], name="unique_finding_order"),
8282
]
8383
indexes = [models.Index(fields=["finding", "order"]), models.Index(fields=["vulnerability"])]

0 commit comments

Comments
 (0)