CreatedAt and LastUpdated - do you use it?
Hi fellow developers!
Curious if you guys use CreatedAt and LastUpdated properties in your classes?
Created to stamp when the record was created and LastUpdated when it was last updated. Where it can be useful - almost everywhere )) I find it convenient in records sorting (e.g. by creation or last update), in sync (with other systems), and so on, for better analytics.
Do you use it all the time for all the classes?
If don't, why not? What do you use instead?
What property type do you use - %TimeStamp? %DateTime?
What is the best practice to have CreatedAt filled automatically during creation and LastUpdated on every successful save (guess it could be in %OnSave)?
Please share your experience /thoughts?
Comments
I believe it is a good way if you use ORM:
Property CreatedAt As %TimeStamp [ InitialExpression = {$ZDATETIME($HOROLOG, 3)}, Required ];Thank you, @Andrew Sklyarov ! No %OnSave callback is needed for the CreatedAt property in this case
Just've published the shvarov-persistent package once installed by
USER>zpm "install shvarov-persistent"
will add shvarov.persistent.base class which can be used as an ancestor after %Persistent, like:
Class yourclass Extends (%Persistent, shvarov.persistent.base), which will add two properties:
Property CreatedAt As %TimeStamp [ InitialExpression = {$ZDT($H, 3)} ];
Property LastUpdate As %TimeStamp [ SqlComputeCode = {set {*}=$ZDATETIME($HOROLOG,3)}, SqlComputed, SqlComputeOnChange = (%%INSERT, %%UPDATE) ];Whoops, I replied to the wrong comment somehow. Sorry!
Edit: for some reason when I clicked on the Reply button on Evgeny's comment above, it was initially showing this reply under Sergei's post below. Then when I left the page and came back, it was in the right place. Firefox being weird on me, I guess.
I have done those two, plus in certain cases a "CreatedBy" and "LastUser" that are automatically computed to the $USERNAME in insert and on insert/update.
like LastUser property too - seems helpful
As this stands, isn't it possible for developers to accidentally SET the CreatedAt property?. I think it is best if this was read only, to avoid bad code accidentally corrupting this field.
I agree. I changed it to "not read-only" as I wasn't to manage unit-tests without it :)
Don't know how to mark an object "modified" - otherwise, %Save() doesn't trigger the calculated property to update.
But I agree - read only is much better.
Yes we usually use both, but naming should be consistent - I like DtCreated and DtUpdated because it will sort close together, but CreatedAt and UpdatedAt will do as well
I really like that idea, having them close together is extremely helpful. We always use the created and updated properties as well, with %OnAddToSaveSet() triggers for both
@Ben Spead it's great you mentioned %OnAddToSaveSet() triggers - how do you manage cases when records were changed by CREATE/UPDATE SQL query? These triggers not fire in this case, right?
Great idea on DtCreated DtUpdated naming
In interop Ens.MessageHeader, we have TimeCreated and TimeProcessed. I would along the same lines and have TimeCreated and TimeUpdated. I find Time… more appropriate as those are time stamps, not dates.
thanks @Robert Barbiaux !
The compute triggers, %%INSERT and %%UPDATE are, in my opinion the best option. They are specifically supported for this purpose and are completely seamless between SQL and Objects. Callbacks and other options may not be seamlessly supported by both filers.
Thanks @Daniel.Pasco. This is what I used in the example class.
Yes, it's great that we have it now in IRIS.