BuyLog In
Ticket Q414772
Visible to All Users
Duplicate

We have closed this ticket because another page addresses its subject:

Specific scenarios with calculated properties defined via the PersistentAlias attribute where the performance can be improved

PersistentAlias (or Calculated for DC) fields are evaluated record by record

created 13 years ago

If a business object contains a persistent alias, list view evaluates the property for all lines by executing a general select (not a count sql for example). In linq queries, these persistent aliases are transformed to related sql's so performance is very high. I know I can use Linq for XAF list views but it causes loosing many functionalities in list view. I also checked that if I define a criteria over persistent alias in list view criteria property, it is evaluated by transforming to related sql.

So is there a way to make xaf list views interpret the related persistent alias and transform it to for example count statement?

Below is a select statement which correctly filters list view according to detail item count without loading all details by using selects. (Linq also correctly create selects by interpreting persistent alias attributes so I think list view loading can be optimized dramatically.)

select N0."Oid",N0."Name",N0."OptimisticLockField",N0."GCRecord" from "dbo"."Master" N0
where (N0."GCRecord" is null and ((select count(*) as Res from "dbo"."Detail" N1 where ((N0."Oid" = N1."Master") and N1."GCRecord" is null)) > 999))

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

    Hello,
    We could replicate this problem with a non-XAF sample project where the following field was used:

    C#
    [PersistentAlias("Details.Count")]  
        public int DetailCount {  
            get { return Convert.ToInt32(EvaluateAlias("DetailCount")); }  
        }

    We need some additional time to research this behavior. Your patience is highly appreciated.

    Sign in to comment on this post

    Answers

    created 13 years ago (modified 11 years ago)

    Hello Gokcer,
    When the property is declared via the PersistentAlias attribute, the expression specified in this attribute is only evaluated on the server side for grouping, sorting, filtering, and summary calculation. When such a property is shown in a grid, its getter is invoked, where the EvaluateAlias method is called. This method evaluates the expression on the client side, and this causes the behavior you noticed. To avoid this, you can either use the Session.Evaluate method instead of the EvaluateAlias method to calculate the DetailCount value on the server side (in this case, a separate query will be executed for each record as well, but detail records will not be loaded to the client) or use the Session.PreFetch method to load all detail collections in a single query (however, it will be difficult to do this in Server Mode).

      Show previous comments (3)
      Anatol (DevExpress) 13 years ago

        We already have a corresponding 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. Since the issue is urgent for you, you can create a database view with the required calculated column and map the business class to it as a workaround.

        GG GG
        Gokcer Gokdal 13 years ago

          Thanks Anatol. I am impatient for this feature because as I said before, it blocks my many business cases. For example I want to add an "Active" field according to DateTime of a property of the object and my program stucks. There are many many cases like these, not only count or sum. I can not tell how important this property for an enterprise project.
          Again thank you for your valuable time.
          Sending my best wishes to you, Dennis and all DevExpress team. :=)

          Anatol (DevExpress) 13 years ago

            You are welcome!

            Sign in to comment on this post

            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.