Interroga tutto. Rielabora niente.

iterateChangesSince() è l'unica base per viste virtuali, ricerca full-text, sincronizzazione con sistemi esterni e analisi su misura. Impari una sola API e hai accesso a tutti gli schemi di interrogazione.

Le viste virtuali si estendono su più database dentro un tenant, attraverso tenant diversi, oppure mescolano dati locali e remoti — senza spostare documenti. Ideali per dashboard consolidati e rendicontazione tra organizzazioni.

Lo store append-only conserva ogni modifica. Interroga qualsiasi stato passato, confronta l'evoluzione dei documenti nel tempo, crea snapshot del database a una data precisa e costruisci audit trail completi — tutto dagli stessi dati.

• Basato su cursore — passa null per la scansione iniziale, poi l'ultimo cursore restituito per gli aggiornamenti incrementali
• Ordine di modifica — i documenti arrivano dalla modifica più vecchia in avanti, così gli indici vedono una progressione coerente
• Attento alle eliminazioni — i documenti eliminati compaiono con il flag isDeleted(), per rimuoverli in modo pulito dagli indici
• Batch guidato dal consumer — il generatore asincrono si può fermare in qualsiasi punto e riprendere più tardi

• O(changed) — ogni esecuzione incrementale elabora solo i documenti modificati dall'ultimo cursore
• Nessuna scansione completa — l'indice interno tiene traccia di (lastModified, docId), così il cursore riprende in modo efficiente
• Consumer sostituibili — un solo flusso di modifiche può alimentare più indicizzatori in un'unica passata
• Funziona offline — gli indici si aggiornano in locale; la sincronizzazione porta le modifiche remote e gli indicizzatori elaborano il delta

• Colonne di categoria — raggruppano i documenti in gerarchie annidate (per esempio Reparto > Anno > Trimestre)
• Colonne ordinate — ordinano le voci dentro ogni categoria per uno o più campi
• Colonne di totale — SUM o AVERAGE automatica per categoria, aggiornata in modo incrementale
• Colonne di visualizzazione — dati aggiuntivi mostrati accanto a ogni voce
• Funzioni di valore — calcolano i valori di colonna al volo dai dati del documento

• Espandi e comprimi — entra nelle categorie o richiudile, come in un gestore di file
• Navigazione per posizione — salta a "1.2.3" (prima categoria, seconda sottocategoria, terza voce)
• Selezione — seleziona singole voci o intere categorie per operazioni di massa
• Callback per il controllo degli accessi — filtrano le voci visibili per ogni utente senza cambiare la struttura della vista
• Iterazione in avanti e all'indietro — percorri l'albero nelle due direzioni

Unisci un database di prodotti statunitense e uno europeo in un unico catalogo. La vista categorizza e ordina attraverso entrambe le sorgenti. Ogni voce porta con sé il suo origin, così l'interfaccia può mostrare la regione di provenienza.

Estendi le viste su MindooTenant diversi, per rendicontare tra organizzazioni. Due organizzazioni condividono dati in un terzo tenant; una vista consolidata aggrega i ricavi di tutti e tre — e ogni tenant mantiene la propria amministrazione indipendente.

Ogni fornitore di dati tiene il proprio cursore in modo indipendente. Una chiamata a view.update() elabora solo i documenti cambiati in ciascuna sorgente dall'ultima esecuzione. Con view.updateOrigin("us-products") puoi anche aggiornare un singolo origin.

La ricerca full-text lato client è il complemento naturale della cifratura end-to-end — e MindooDB la porta con sé: un indice full-text attivabile a scelta e mantenuto dal changefeed (basato su MiniSearch), conservato cifrato a riposo e integrato direttamente nelle query, con risultati ordinati per pertinenza.

• Contenuti di ogni tipo — testo semplice, campi di testo Automerge, porzioni di rich text, testo degli allegati (PDF/Office)
• Integrazione nelle query — combina la corrispondenza full-text con filtri strutturati e ordinamento per pertinenza
• Consapevole della lingua — tokenizzazione con Intl.Segmenter, configurabile per ogni database
• Indicizzatori esterni — FlexSearch, Lunr.js o sistemi propri restano collegabili tramite il changefeed

Costruisci pipeline di dati che reagiscono alle modifiche dei documenti. Lo schema del generatore asincrono ti permette di elaborare le modifiche al tuo ritmo, con la backpressure già inclusa.

• Feed di analisi — mandano metriche aggregate ai dashboard
• Trigger webhook — avvisano i sistemi esterni quando cambiano documenti precisi
• Pipeline ETL — estraggono e trasformano i dati per i sistemi di rendicontazione
• Replica — rispecchia i dati su sistemi secondari con semantica exactly-once

• getDocumentAtTimestamp() — recupera lo snapshot di un documento a una qualsiasi marca temporale passata, applicando tutte le modifiche fino a quel momento
• getAllDocumentIdsAtTimestamp() — ottiene in modo efficiente tutti gli ID dei documenti esistenti in un preciso momento, senza caricarne il contenuto
• Gestione dei documenti eliminati — distingue tra "non esisteva ancora" (restituisce null) e "è stato eliminato" (restituisce il documento con il flag isDeleted())

• iterateDocumentHistory() — percorre ogni modifica dalla creazione allo stato attuale, in ordine cronologico
• Metadati dell'autore — ogni modifica porta la marca temporale e la chiave pubblica di firma dell'utente che l'ha fatta
• Copie indipendenti — ogni versione restituita è uno snapshot a sé, che puoi conservare e confrontare senza rischi
• Rilevamento delle modifiche — restituisce solo se il documento è cambiato davvero (salta gli aggiornamenti a vuoto)

Crea una copia congelata del database alla fine di ogni trimestre fiscale. I revisori possono verificare in modo indipendente lo stato dei documenti, le firme di paternità e la cronologia delle modifiche — tutto dimostrabile crittograficamente.

Confronta gli insiemi di documenti a due marche temporali per scoprire cosa è stato creato, modificato o eliminato nel frattempo. In combinazione con getDocumentAtTimestamp() vedi esattamente come si sono evoluti i singoli documenti.

Esegui la stessa vista virtuale o la stessa query su snapshot del database a date diverse. Confronta i risultati mese su mese o trimestre su trimestre senza mantenere database di rendicontazione separati.

In MindooDB il contenuto dei documenti è cifrato end-to-end. Il server archivia solo testo cifrato e non può eseguire query. È un compromesso deliberato a favore della sicurezza: riservatezza prima della comodità lato server. L'indicizzazione lato client restituisce le possibilità di interrogazione che ti aspetti — con la garanzia che i tuoi dati non siano mai esposti al server.

L'approccio incrementale mantiene tutto questo praticabile anche su grandi volumi. Invece di ricostruire gli indici da zero dopo ogni sincronizzazione, il cursore riprende esattamente da dove si era fermato ed elabora solo il delta. In un database con 100.000 documenti, di cui 50 cambiati dall'ultima sincronizzazione, l'indicizzatore elabora 50 documenti — non 100.000.

Lo store append-only di MindooDB è ciò che rende possibili tutti questi schemi. Poiché le modifiche non vengono mai sovrascritte:

• I cursori sono stabili — l'ordine delle modifiche non cambia, quindi riprendere da un cursore è sempre coerente
• Il viaggio nel tempo non costa nulla — la cronologia completa è già archiviata; non servono log o snapshot aggiuntivi
• Gli audit trail sono integrati — ogni modifica è firmata e datata dal suo autore
• Gli aggiornamenti incrementali sono corretti — il flusso delle modifiche è completo e ordinato; nessun aggiornamento va perso

È il contrario di quanto accade nei database modificabili, dove tracciare le modifiche, tenere la cronologia e indicizzare in modo incrementale richiede infrastruttura aggiuntiva (WAL, CDC, change stream, tabelle di audit).