Come chiamare i dati che non sono ancora pronti?

Penso che tu stia descrivendo due diverse situazioni:

what do you call data that is not yet fresh, and has never been fresh?

Garbage . Quando leggi un valore prima che avvenga l'inizializzazione, leggi i dati non inizializzati. È stato lasciato in qualsiasi stato da qualsiasi cosa lo abbia toccato per ultimo. Non puoi nemmeno chiamarlo casualmente perché non ci si può fidare che sia casuale. Il suo valore deriva da qualcosa che non rientra nell'ambito del tuo ragionamento.

operation that fails if performed on an entity that's never been flushed to the database.

Questi dati non sono sincronizzati. Un buon design ha una, e una sola, inequivocabile fonte di verità per ogni informazione. Un design efficiente spesso esegue copie locali e veloci da quella sorgente e tenta di mantenerle sincronizzate con quelle più lente e persistenti. Puoi chiamare questo caching, paging, virtualizzazione, o qualsiasi altra cosa ma quando fallisce hai la stessa idea rappresentata in due stati diversi perché queste due copie non sono sincronizzate. Almeno questo è un nome per questo.

Nel teorema CAP lo chiameresti partizionato. Per qualche motivo i dati non sono ancora stati scaricati sul DB e ora si desidera eseguire un'operazione prima che lo sia. Se hai permesso che l'operazione avesse successo ora il risultato sarebbe incoerente con il DB. Dal momento che dici che fallirà il risultato è una mancanza di disponibilità. Queste tre idee: Coerenza, disponibilità e tolleranza delle partizioni danno al teorema CAP il suo nome.

Ciò che è nato da questa idea era un concetto di Eventual Consistenza che incoraggia un design che si aspetta che la coerenza fallisca occasionalmente ma ha una strategia per correggerlo, piuttosto che rotolare e morire con un errore nel momento in cui viene rilevato.

Che cosa dovresti fare dipende da te. Ma questi sono i nomi che ballano attorno a questa idea.

Se non è mai stato salvato nel database, lo chiamerei "unsaved" o "uncommitted", ma per chiarezza, sarei un po 'più prolisso in cose come documentazione e messaggi di errore, e mi riferisco a loro come "entità che non sono state salvate nel database."

Chiamerei tali dati "futuri" . Ciò comunica chiaramente l'intenzione che tali dati saranno in futuro impegnati nel database. Se c'è la possibilità che la transazione non venga commessa (l'applicazione esegue il rollback della transazione), tuttavia, allora forse preferirei il termine "uncommitted" o "dirty". Se sei ragionevolmente certo che la transazione verrà eventualmente commessa, allora "futuro" è la parola giusta. Soprattutto se hai combinato la parola con "dati": "i dati futuri" dovrebbero essere chiari a tutti.

Si noti che nel mondo di programmazione simultanea, "futuro" ha un significato leggermente diverso: i dati non sono stati ancora calcolati. Questo doppio significato di "futuro" può essere o non essere un problema a seconda del contesto. Certamente vedo che entrambi i significati del "futuro" sono analoghi.

In un contesto ORM la metafora vecchia / fresca non si applica realmente. Sembra più una cosa per i dati dei report che vengono aggiornati regolarmente. Più a lungo è passato dall'ultimo ciclo di aggiornamento, più i dati diventano obsoleti.

I dati a cui fai riferimento non sono ancora presenti nello store, è un oggetto istanziato in memoria che può essere o non essere mantenuto in un secondo momento. Se si desiderano i nomi per il ciclo di vita dei dati in un contesto ORM, vorrei pensare a termini diversi del tutto. Come

Initiated    - unpersisted new object
Created      - persisted for the first time
BeingEdited  - someone is working on an update
Updated      - changed at least once
Deleted      - flagged for deletion
Purged       - irretrievably destroyed
Archived     - backed up, there but not readily accessible

Potresti occuparti solo di una parte di questi o pensarci ancora, a seconda dell'applicazione.