4.5 KiB
Sì. Se in questo momento stai usando Scan invece del watcher, il percorso è diverso perché entra in gioco il vecchio scanner che abbiamo già visto, in particolare scanFile.js.
Da quello che abbiamo verificato, il flusso è questo.
Flusso Scan attuale SCAN │ ▼ scanner foto │ ▼ scanFile.js │ ┌──────┴───────┐ │ │ ▼ ▼ processFile() foto esistente? │ ▼ thumbnails │ ▼ photos DB │ ├──────────────► trigger SQLite │ │ │ ▼ │ face_scan_jobs │ │ │ ▼ │ FACE DAEMON │ ▼ photo_changes added / updated
Questo deriva direttamente dal scanFile.js che abbiamo visto. Per una nuova foto fa:
await db('photos').insert(...);
await db('photo_changes').insert({ photo_id: meta.id, user, change_type: 'added', timestamp: ... });
e per una foto modificata:
change_type: 'updated'
Face
Anche usando Scan, Face continua a utilizzare il daemon.
Questo perché non è scanFile.js che avvia Face. È il trigger SQLite che abbiamo verificato:
scanFile ↓ INSERT photos ↓ photos_face_enqueue_insert ↓ face_scan_jobs ↓ FACE DAEMON
E per una modifica:
UPDATE photos ↓ photos_face_enqueue_update ↓ face_scan_jobs ↓ FACE DAEMON
Questa parte quindi è già correttamente disaccoppiata.
Geocode invece va verificato
Qui c'è una differenza importante.
Nel nuovo scanPhotoSingle.js abbiamo visto esplicitamente:
await enqueueGeocodeJob(...)
quindi con Photo daemon sappiamo che:
Photo daemon → geocode_jobs → Geocode daemon
Nel pezzo di scanFile.js che abbiamo esaminato non abbiamo invece verificato l'enqueue geocode.
Quindi non darei ancora per certo che lo Scan utilizzi il nuovo Geocode daemon.
E la Gallery?
Anche questa è diversa.
Il vecchio Scan scrive:
photo_changes
ma abbiamo verificato che attualmente nessuno consuma photo_changes.
Bisogna però ricordare che diverse route autoScan.js effettuano direttamente:
wss.broadcastToUser(...)
e il nostro grep aveva trovato vari:
type: "added"
dentro autoScan.js.
Quindi è molto probabile che con lo Scan il percorso realtime sia:
SCAN │ ▼ scanFile / scanner │ ▼ photos DB │ ▼ autoScan.js │ ▼ broadcastToUser() │ ▼ WebSocket │ ▼ sync.js │ ▼ Gallery
e non utilizzi la nuova server_event_outbox, perché Scan viene eseguito dentro il processo server e può accedere direttamente al WebSocket.
In sostanza oggi abbiamo probabilmente due strade NUOVA FOTO │ ┌────────────┴─────────────┐ │ │ SCAN WATCHER │ │ ▼ ▼ scanFile.js photo_ingest_jobs │ │ │ PHOTO DAEMON │ │ └────────► photos ◄────────┘ │ ▼ FACE trigger │ ▼ FACE DAEMON
Per la gallery:
SCAN │ └──► autoScan → WebSocket ──────────────► Gallery
PHOTO DAEMON │ └──► server_event_outbox → Server → WS ─► Gallery
Questa doppia strada può essere perfettamente corretta: l'outbox serve solo quando il produttore è un processo esterno al server.
Se vuoi capire esattamente il flusso Scan senza supposizioni, il prossimo controllo ideale è:
grep -nE "scanFile|broadcastToUser|type: ['"]added|type: ['"]updated|enqueueGeocode"
routes/autoScan.js
e:
grep -nE "enqueueGeocode|geocode|broadcast|recordChange"
api_v1/scanner/scanFile.js
Con questi due output possiamo confrontare precisamente:
SCAN vs WATCHER + PHOTO DAEMON
e verificare se anche Scan usa i daemon Geocode e Face e come aggiorna la galleria.