Is there a performance effective way to create non-persistent properties to pull the datetime values for creation date time and last updated datetime from the audit trail?
We have closed this ticket because another page addresses its subject:
PersistentAlias with Join - PerformancePull CreatedDateTime and UpdatedDateTime values from audittrail
Answers approved by DevExpress Support
Hello Nate,
I now fully understand your intent and scenario. Yes, I also share your concern about performance, because getting a scalar field from the same table and making selects and joints from a different table are two different things. It is not possible, however, to predict whether the performance difference will be noticeable or not, because everything depends on the amount of history data, existence of indices and other factors. So, my best suggestion is to compare these two approaches on real data. You can query history data via the AuditDataItemPersistent persistent class, as follows:
C# [PersistentAlias("[<AuditDataItemPersistent>][^.Oid=AuditedObject.GuidId].Max(ModifiedOn)")]
public DateTime ModifiedOn {
get {
return Convert.ToDateTime(EvaluateAlias("ModifiedOn"));
}
}
//OR
[PersistentAlias("[<AuditDataItemPersistent>][Contains(AuditedObject.TargetKey, ToStr(^.Oid))].Max(ModifiedOn)")]
public DateTime ModifiedOn {
get {
return Convert.ToDateTime(EvaluateAlias("ModifiedOn"));
}
}
If the difference is huge, I think that such a small duplication is not that big problem at all. In any event, I look forward to hearing about your results.
UPDATE:
Just blogged about this scenario: http://dennisgaravsky.blogspot.com/2013/03/avoiding-data-redundancy-for-modified.html
@Nate: You can refer to Kim's ticket: PersistentAlias with Join - Performance, where it is described how to get the UserName.
@Kim: Thanks for posting, I really appreciate it, because I forgot that you dealt with the same task in the past. I have updated my blog post to mention your experience as well. If you run your own blog, please share a link with me. I am eager to learn how you are developing using our tools and what problems you are experiencing, solving, etc. I know you have huge experience and believe it will be helpful for other users.
Thanks Kim.
Well that's too bad about the performance. I'm sure I will run into the same thing. AuditTrail already bogs a lot of my users down.
Perhaps the ticket referenced here will make it acceptable? http://www.devexpress.com/Support/Center/p/S36566.aspx
Dennis, implement that ticket real fast! :)
Nate, while I cannot promise any time frame for implementing that feature request, I suggest that instead, you duplicate the "ModifiedOn" property if the previous solution does not meet your needs. In addition, you can use the Lightweight auditing mode: http://documentation.devexpress.com/#Xaf/CustomDocument2783 to collect less history data.
Hello Nate,
I believe there must be a solution to meet your requirements (after all the Audit Trail modules store data history via the same persistent objects, which you can query at any time), but we need more information on your scenario and ultimate goal. I am afraid it is completely unclear at the moment.
Well, on my BO I want to replace four persistent fields UpdatedOn, UpdatedBy, CreatedOn, CreatedBy with non-persistent fields that pull this information from AuditTrail since it's already there and available. These values are to be shown on detail views so at a glance the user can get this info without going into the audit trail tab. I'm duplicating data by storing these values myself. However the concern is that audittrail is so large that querying this data will be too taxing on performance.