Difference between revisions of "Timestamps"
| Line 12: | Line 12: | ||
=== CreationTimeStamp === | === 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 === | === UpdateTimeStamp === | ||
Revision as of 05:43, 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
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.
