The ideaIf you are dealing with data, you want to keep it up-to-date. But some data-objects are expiring. So the idea is to define a state a data-object can have. That could be "active" or "expired".
But there is also the possibility that someone wants to predefine data and then switch the state at the right time. In that case we could introduce another state called "prepared".
Defining the statesA data-object can have 3 states.
- prepared: A data-object is not active yet but will be in the future.
- active: A data-object is currently up-to-date and will be used for all program-functionality.
- expired: A data-object reached the end of its data-life-cycle and will not be used any more.
Saving the stateIn a common relational database system this information could be saved in a single integer or char-field. But also there could be used date or timestamp-fields. Therefore let's use "activation date" and "expiration date" as terms to define those fields.
So, if the current date is before the activation date, the record is in state "prepared". If the current date is after the expiration date, the condition for the state "expired" would be met. The third case, if the current date is between activation date and expiration date, then the record is active.
If some of the date-fields are null, the cases become a little more complex.
- If there is neither "activation date" nor "expiration date" defined, then a record is in state "active".
- If there is no activation date, but an expiration date, you have to compare the current date with the expiration date to determine the state "active" or "expired"
- If there is no expiration date, but an activation date, the current date decides on "prepared" or "active".
Inform the userDue the best practice a user should not need to think about what he/she does, we should provide the user with some extra information. If a user only looks at the state of a data-object, it is necessary to have a look at the activation date and the expiration date. In some cases that attribute should also be hidden from the user for security or data-protection reasons.
To make it easier for the user to understand the data-life-cycle, we could extend the caption for the state.
We can add "activating" in the prepared state, if an activation date was defined, and we can append the string "expiring" if an expiration date was defined before. If the state will not change automatically, we omit this extra information.
Of course, if you determine the state through the comparison with the actual date, "prepared" can never occur without the appended "activating"-string, but for consistency it is recommended to show it to the user, either.