Hi,
I want to show the lastmodifieduser and lastmodifieddate of a bo. Because I already have the AuditTrailModule active for this bo type I want to use this information. I have coded two persistentalias properties for that:
C#[PersistentAlias("[<AuditDataItemPersistent>][AuditedObject.GuidId = ^.Oid].Max([ModifiedOn])")]
public DateTime? LastModifiedDate
{
get { return EvaluateAlias("LastModifiedDate") as DateTime?; }
}
[PersistentAlias("[<AuditDataItemPersistent>][ModifiedOn = [<AuditDataItemPersistent>][AuditedObject.GuidId = ^.^.Oid].Max([ModifiedOn]) And AuditedObject.GuidId = ^.Oid].Max(UserName)")]
public string LastModifiedUser
{
get { return EvaluateAlias("LastModifiedUser") as string; }
}
Unfortunately the performance is not so good - especially if you have
many audittrail records (about 500000 with indicies at the involved
columns). It looks like XPO selects the bo records first and than
separately for each bo instance two selects for the two
persistentaliases. Wouldn't it be possible to select such
persistentaliases with one select together with the rest of the bo
properties? Or can I modify my persistentalias criterias to optimize the
performance?
Thanks.
Best regards,
Matthias
Hi Matthias,
In the meantime, is not a small de-normalization (making LastModifiedDate persistent) for this specific case or even creating an XPView/LINQ-based ListView for this particular case an option for you? Or it is important to save standard XAF capabilities (e.g., CRUD) for this ListView?
In addition, I suggest you review the following tickets in our database: Q414772 S30035
Hi Dennis,
thanks for additional answer and your hints to this tickets :)
For my special usecase I think its okay to have two persistent properties, which are filled in the onsaving method with the SecuritySystem.CurrentUsername and DateTime.Now properties.
In most cases, the persistentalias is based upon properties which are already loaded and we don't use the session.evaluatealias method their. Because for us its much faster to calculate such expression in the getter at client side. So in this cases the businesslogic is coded twice - first a criteria for persistentalias and second its coded for fast client side calculations). If DevExpress would find a solution for that, we could optimize that maintenance issue. The are really rare cases when a persistentalias is calculated bases upon values which are not already loaded, such as the example I posted.
Thank you for your reply. We already have a similar feature request: Optimize SQL query generation for nested persistent alias properties. You can add it to favorites to be automatically notified when its state is changed. I am afraid that I cannot provide you with any time frames as to when it is implemented.