The JADE 2022 release meets tomorrow’s business demands.
We would like to migrate data from one JADE database to another.
Our issue is the creationTime in the new database will not match that of the old database and all objects will end up with a creationTime of NOW being the time of the migration.
We would like to be able to set the creationTime on imported objects so that creation times match the creation times in the source database
Guest
I think it'd be good to have an Object::creationTimeUTC() method available. With this in place, using an additional created time stamp property would be redundant - except for the data migration scenario.
Similar to a data migration scenario, we've a process for creating a cut-down copy of our production environments for the purposes of testing. The process for this starts with an empty environment, which is then populated with a selection of records extracted from a backup, including any other related records referred to from those initially selected.
While experienced developers probably tend to use a created time stamp property like BJ's described, there's always the possibility of pre-existing functionality relying on Object::creationTime being consistent with other data created at the same time originally, which may suffer from inconsistent behavior during testing in a cut-down environment, or where it's been imported/migrated from elsewhere.
Overall, can't say I'm a fan of the idea in principle, but can see why it'd be useful to have something like an Object::setCreationTime for exceptional use cases like data migration. Beyond that, I can't see why you'd ever need to edit a creation timestamp afterwards, so perhaps if implemented, Object::setCreationTime could throw an exception when it's not being called in the same transaction which created the object.
We would be reluctant to provide a public API that allows users to change the internal creationTime value on an object after it has been created.
As with any JEDI idea, it is valuable to capture user requirements and the follow up comments, questions and concerns. There are generally several ways to address a problem as indicated by the discussion so far.
The scenario is a bulk data import and the main requirement is to set the creationTime for objects
that are imported, that does not mean there should be a way to change creationTime after the import -- and personally I would be against that.
Re: BJ's remark:
We also had a need to display this time in the locale/timezone of the current user, so we actually store all our dates/times in UTC.
Storing timestamps in UTC is very good practice. In some cases it is useful to have the TimeZone relevant to the data source as well. For example if you are dealing with events that can originate from different timezones.
As it happens, the internal creationTime stored on objects is stored as a UTC time. The Object::creationTime() method converts this to a local time in the executing TimeZone, which may not be the end user's time zone.
It might be useful to have an Object::creationTimeUTC() method so that you could convert the time to a TimeZone of choice. What do others think?
I would prefer if this idea was not implemented, possibly this could be an option?
When resolving issues, knowing exactly when the object was created within the environment is beneficial. Especially if it was part of a migration. It might even be relied on during a data fix up if the migrated data has any particular issues.
That creationTime roughly coincides with when the object was journalled initially. If you rely on that information, why not have a TimeStamp on those objects you require it for?
This is one of the reasons we added our own 'creationTime' property on our base level model object and have a JadeUnitTest that makes sure no developers have inadvertently used the Jade supplied property. We also had a need to display this time in the locale/timezone of the current user, so we actually store all our dates/times in UTC and convert to the local date/time display for the current user using the UTC offset rules that applied to their timezone on that date/time. There may be auditor considerations/concerns should Jade allow the Jade supplied creationTime property to be changed, especially for financial systems.