13 lines
1.3 KiB
Markdown
13 lines
1.3 KiB
Markdown
# Importqueryanalyse 0.3.14
|
|
|
|
De hot path liep van `process_raw_document` via parsing en `persist_draft` naar employer-resolutie, deduplicatie, alias/provenance, versiebeheer en scoring. Profiling wees vier dominante oorzaken aan:
|
|
|
|
1. Dezelfde werkgever en actieve profielen werden voor elk document opnieuw opgehaald.
|
|
2. Veldprovenance gebruikte per veld een afzonderlijke `update_or_create`.
|
|
3. Een inhoudelijk ongewijzigde waarneming schreef opnieuw een versie en berekende alle scores volledig.
|
|
4. `last_changed` verschoof ten onrechte bij alleen een nieuwe `last_seen`-waarneming.
|
|
|
|
De oplossing blijft binnen de modulaire monoliet en transacties: een import-run krijgt een lokale `PersistenceContext`, provenance wordt per alias gelezen en gebundeld geschreven, versies ontstaan alleen bij inhoudelijke wijziging en een ongewijzigde job kopieert het laatste ongewijzigde scoresnapshot. Daardoor blijft iedere `ScoreRun` historisch aanwezig, terwijl deterministische scoring niet opnieuw wordt uitgevoerd. De cache leeft nooit buiten één seriële import-run en verandert workerisolatie of deduplicatieregels niet.
|
|
|
|
De database-executieteller rapporteert per 250 items exact: 1.256 SELECT, 1.003 INSERT, 499 UPDATE, 253 SAVEPOINT en 253 RELEASE; totaal 3.264 importexecuties. De drie officiële iteraties geven identieke queryfamilies.
|