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.

  • "Not-yet-persisted"? Feb 16, 2018 at 2:06
  • I was hoping for something not specific to databases Feb 16, 2018 at 3:07
  • 1
    Unpersisted springs to mind, but if you want to stick with the food metaphor (stale, fresh, etc) you might consider "raw". Feb 16, 2018 at 3:08
  • In some contexts, it could be considered "staged"
    – e_i_pi
    Feb 16, 2018 at 5:51
  • 3
    "new", "volatile" or "dirty" might be used.
    – S.D.
    Feb 16, 2018 at 6:25

4 Answers 4


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.

  • All of these are really good answers to a very open ended question. But this is the most detailed, so I'll accept it. Feb 20, 2018 at 19:22

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.

  • My thought as well +1
    – Igwe Kalu
    Feb 17, 2018 at 21:27

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.