I often see the term stale used to refer to data that is out of date, and fresh to describe data that is up to date. Both of those make sense to me.
But what do you call data that is not yet fresh, and has never been fresh?
The situation that made me ask this question is I'm working on an application that uses an ORM, and there's an operation that fails if performed on an entity that's never been flushed to the database. I wasn't sure what to call the entity in that state.
I think you're describing two different situations:
what do you call data that is not yet fresh, and has never been fresh?
Garbage. When you read a value before initialization happens, you read uninitialized data. It's been left in whatever state from whatever touched it last. You can't even call this random because it can't be trusted to be random. It's value came from something outside the scope of your reasoning.
operation that fails if performed on an entity that's never been flushed to the database.
This data is out of sync. A good design has one, and only one, unambiguous source of truth for every piece of information. An efficient design often makes local, fast, copies from that source and attempts to keep them in sync with the slower, more persistent ones. You can call this caching, paging, virtualization, or whatever but when it fails you have the same idea represented as being in two different states because these two copies are out of sync. At least that's one name for it.
In the CAP theorem you'd call it partitioned. For some reason the data has not yet been flushed to the DB and now you wish to perform an operation before it is. If you allowed the operation to succeed now the result would be inconsistent with the DB. Since you say it will fail the result is a lack of availability. Those three ideas: Consistency, Availability, and Partition tolerance give the CAP theorem its name.
What grew out of this idea was a concept of Eventual Consistency which encourages a design that expects consistency to fail on occasion but has a strategy to eventually correct it rather than rolling over and dying with an error the moment it's detected.
Which you should do is up to you. But these are the names that dance around this idea.
If it's never been saved to the database, I'd call it "unsaved" or "uncommitted", but for clarity, I'd be a little more verbose in things like documentation and error messages, and refer to them as "entities that have not been saved to the database."
I would call such data "future". This clearly communicates the intention that such data will in the future be committed to the database. If there's the possibility that the transaction will not be committed (the application rolls back the transaction), however, I then perhaps would prefer the term "uncommitted" or "dirty". If you are reasonably certain that the transaction will be eventually committed, then "future" is the right word. Especially if you combined the word with "data": "future data" should be clear to everyone.
Note that in the concurrent programming world, "future" has a slightly different meaning: the data has not been calculated yet. This dual meaning of "future" may be or may not be a problem depending on the context. Certainly I see that both of the meanings of "future" are analogous.
In an ORM context the stale/fresh metaphore does not really apply. That seems more like a thing for report data that gets updated on a regular basis. The longer it has been since the latest update cycle, the more stale the data gets.
The data you refer to isn't there yet in the store, it is an instantiated object in memory that may or may not be persisted later. If you want names for the data life cycle in an ORM context I would think of different terms altogether. Like
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
And you may care about only a part of these or think up some more, depending on your application.
