Ticket Q416995
Visible to All Users
Duplicate

PersistentAlias with Join - Performance

created 13 years ago

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

Comments (3)
Dennis Garavsky (DevExpress) 13 years ago

    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.

      DevExpress Support Team 13 years ago

        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.

        Answers

        created 13 years ago (modified 13 years ago)

        Hi Matthias,
        Thank you for your question. Unfortunately, the XPO Library does not provide the capability to include persistent alias expressions with the main select query. Alias expressions you use cannot be simplified, either.

          Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

          Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.