Difference between revisions of "Timestamps"
| Line 25: | Line 25: | ||
# When a new primary child is added to a relation. Primary in this context means the first level of object relation, the directly connected object so to say. That means adding such a child counts as a change for the owner object and the UpdateTimeStamp will be set. A child can be anything (Attributes, Relationdata, etc). | # When a new primary child is added to a relation. Primary in this context means the first level of object relation, the directly connected object so to say. That means adding such a child counts as a change for the owner object and the UpdateTimeStamp will be set. A child can be anything (Attributes, Relationdata, etc). | ||
| + | <ol> | ||
| + | <li>list item A1 | ||
| + | <ol> | ||
| + | <li>list item B1</li> | ||
| + | <li>list item B2</li> | ||
| + | </ol>continuing list item A1 | ||
| + | </li> | ||
| + | <li>list item A2</li> | ||
| + | </ol> | ||
Revision as of 07:37, 17 September 2019
This page describes the timestamps that are relevant for the role of a service engineer. There are more different timestamps used internally but these should not be mentioned here. There for it is best to understand timestamps in UBIK from a non-developer perspective: From this view we care about 5 different timestamp names and their usage on 4 levels: CreationTimeStamp, UpdateTimeStamp, ValidationTimeStamp, ExportTimeStamp and ImportTimeStamp. The usages are best explained when assigning these timestamps to different levels where they are used:
- On Object(instance)level: cts (CreationTimeStamp), uts (UpdateTimeStamp)
- On Propertylevel: vts (ValidationTimeStamp), CTS, UTS
- On Proxylevel: ets (ExportTimeStamp), its (ImportTimeStamp)
- On ProxyPropertylevel: ets (ExportTimeStamp), its (ImportTimeStamp)
 | Be aware, that SPECIAL CASES WHERE THERE NEEDS TO BE A VALUE CALCULATED FOR A TS BECAUSE THE MOST INTUITITIT IS NOT AVAILABLE |
Contents
On ObjectLevel / BaseClass
CreationTimeStamp
Saves the date and time when an object is created.
The CreationTimeStamp (cts) is set exactly once and in that moment when a new Ubikle is instantiated in the working memory. This time stamp will never be changed by UBIK. This timestamp does not denote when the Ubikle was written to the database eventually.
UpdateTimeStamp
Saves the date and time when an object has been changed. If the UTS is null or “01.01.0001 00:00:00” then return the CTS.
A change is defined by two events:
- When the object changes the UpdateTimeStamp is set. An object is meant to be changed when at least one of its properties has been changed. To know this every property will be asked if it has been changed or not (properties hold this information by themselves). A change of a property means either:
- it’s value has been changed (the property knows its new and old value),
- it’s ValidationTimeStamp has be set
- When a new primary child is added to a relation. Primary in this context means the first level of object relation, the directly connected object so to say. That means adding such a child counts as a change for the owner object and the UpdateTimeStamp will be set. A child can be anything (Attributes, Relationdata, etc).
- list item A1
- list item B1
- list item B2
- list item A2
On PropertyLevel / BaseProperty
UTS
Either this value is 1. the TimeStamp of the LastChange from the PropertyValueChangeLog if the PropertyValueChangeLog is available or 2. the property’s UBIKAttribute.UpdateTimeStamp
CTS
Saves the date and time when a property value is written the very first time.
ValidationTimeStamp
Saves the date and time when a value has been entered or validated on the client. It is sufficient that an existing value is checked on the client. This can be for example by simply pressing an OK button.
