Dove stanno i dati del progetto da ospite, da account attivo e al cambio di account
SlateX tiene i dati dello stato ospite e quelli dello stato con accesso effettuato in due database fisici separati: usano lo stesso modello di dati, ma non sono lo stesso file. Il database ospite porta solo le registrazioni fatte senza accesso; il database dell'account porta le registrazioni dopo l'accesso, e solo questo è configurato per un database cloud privato. Anche al cambio di account l'appartenenza non viene gestita con il criterio «chi è connesso adesso, e quindi tutto gli appartiene», ma record per record secondo le condizioni di identità Apple.
Due database separati rispondono al problema «da che parte finiscono i dati», e non equivalgono a una garanzia di sicurezza, di privacy o di risultati tra dispositivi.
Database ospite e database dell'account sono due file
Il database ospite e il database dell'account stanno entrambi in una sottodirectory dedicata dentro la directory di supporto dell'app. Questa posizione non è una posizione Documents che si esplora direttamente nell'app File, quindi «avere trovato il file del database» non va inteso come «si sono già ottenuti tutti i media», e la sola copia di backup del file del database non va scritta come una soluzione completa di backup.
I due database condividono la stessa istanza del modello di dati, e per questo progetto, scene, record di ciak e materiali di continuità restano espressi dalla stessa struttura. La differenza sta nel punto in cui i dati finiscono su supporto: i dati dell'ospite entrano nel database ospite e i dati dell'account, dopo l'accesso, entrano nel database dell'account. Il codice configura un database cloud privato solo per il database dell'account, e quello ospite non ha alcuna configurazione di caricamento sul cloud per tutta la sua durata. Qui si sta descrivendo un fatto di configurazione del codice, non una conclusione di test che abbia già verificato sul dispositivo che non parte alcun caricamento.
Foto e video non sono la stessa cosa dentro il database
I dati di una foto sono salvati come dati binari dentro il database, e quindi viaggiano insieme alla registrazione del database. Il video sta diversamente: nel database è salvato un percorso che punta a un file locale, e non il file video stesso dentro lo stesso campo del database.
Questa differenza vuol dire che, passando da un dispositivo all'altro, la registrazione della foto e il percorso del video non si possono intendere con lo stesso meccanismo. Il codice può dire che cosa viene salvato nei due casi nel database, ma non può promettere «su un altro dispositivo si ottiene di sicuro» né «non si ottiene di sicuro». Chi legge può trattarli solo come due forme di archiviazione diverse, invece di equiparare la sincronizzazione del database all'arrivo dei file media.
Nel database esiste una registrazione di un media, e questo non vuol dire che il file locale corrispondente sia già comparso su un altro dispositivo.
Dopo l'accesso, l'appartenenza non è un passaggio di proprietà del database intero
L'appartenenza dei dati lato account viene giudicata record per record secondo le condizioni di identità Apple. Il progetto e i record raggiungibili devono poter arrivare a un percorso di appartenenza che corrisponde all'identità corrente, e il fatto che un account sia connesso in questo momento non autorizza a considerare tutto il contenuto del database come suo.
Lo stesso giudizio incide anche sulla possibilità di leggere, migrare o eliminare un record quando si cambia account. Detto in altro modo: lo stato di accesso è solo una delle condizioni che decidono in quale ambiente di dati si entra, e a chi appartiene un record dipende da quale catena di relazioni può percorrere il record stesso fino a un'identità corrispondente.
I dati dell'ospite migrano solo con un accesso voluto dall'utente
Il passaggio delle registrazioni dell'ospite nel database dell'account non succede di sfuggita quando l'accesso viene ripristinato. Solo il percorso in cui l'accesso è avviato di propria iniziativa dalla persona permette di avviare la migrazione dell'ospite; quando l'app ripristina l'accesso da credenziali già presenti, il database ospite non viene trasferito in automatico.
Anche la migrazione è eseguita a fasi: prima si crea uno snapshot dal database ospite, poi si scrivono nel database dell'account gli oggetti migrabili, e successivamente, con un nuovo contesto, si verificano attributo per attributo, relazione per relazione e appartenenza per appartenenza. Solo se la verifica passa, sul lato di origine le registrazioni dell'ospite vengono pulite. Se una fase fallisce, il lato di origine non entra nella fase di pulizia.
Se la verifica non passa l'originale resta fermo: meglio non toccare nulla che toccarne metà. La frase descrive l'ordine di migrazione attuale, e non significa che la rete, il cloud o altri dispositivi abbiano completato qualche verifica aggiuntiva.
Fino a dove arriva questa pagina
Questo meccanismo può rispondere a dove finiscono separatamente le registrazioni dell'ospite e quelle dell'account, quale dei due database è configurato per il cloud privato, in che forma i media compaiono nel database, e come migrano i dati dell'ospite, dopo essere stati confrontati, quando l'accesso è voluto dall'utente. Non dimostra un particolare modello di cifratura né una garanzia di privacy di ampia portata, non può dimostrare che nessuno sia in grado di leggerli e non trasforma una configurazione del codice in un audit di sicurezza già completato sul dispositivo.
Se la domanda diventa «un altro dispositivo mostrerà nello stesso momento lo stesso media», «dopo aver eliminato l'app si può recuperare» o «una certa norma è soddisfatta per questo», questa pagina descrive solo come sono davvero organizzate le cartelle del progetto su questa macchina, e non fa estrapolazioni su questi casi.
FAQ
Lo stato ospite e lo stato con accesso usato lo stesso database?
No. I due stati usano due file di database fisici separati, ma condividono la stessa istanza del modello di dati: le registrazioni dell'ospite finiscono nel database ospite e quelle dopo l'accesso finiscono nel database dell'account.
Anche il database ospite finisce nel cloud privato?
Il codice attuale non configura alcun caricamento sul cloud per il database ospite, e solo il database dell'account è configurato per un database cloud privato. Anche questa formulazione descrive una configurazione del codice, e non equivale ad aver dimostrato con test sul dispositivo ogni comportamento di rete.
Perché foto e video non si possono capire con la stessa aspettativa tra dispositivi?
Perché i dati della foto stanno salvati dentro un campo del database, mentre del video il database conserva un percorso locale. Le due forme di archiviazione sono diverse, e dalla sola esistenza della registrazione nel database non si può dedurre che l'altro dispositivo abbia già il file corrispondente.
Quando passano all'account le registrazioni dell'ospite?
La migrazione dell'ospite può partire solo quando è la persona a iniziare un accesso; il ripristino di uno stato di accesso già esistente non la esegue in automatico. La migrazione passa dalla scrittura e dalla verifica, e se la verifica non passa la registrazione di origine resta.
Axiom One LLC — SlateX. I numeri di questo articolo sono aggiornati al 2026-09-24.