Virtual attributes, performance and generalizations

3
I've been browsing articles and came across this article on performance issues caused by virtual attributes. In particlular: Furthermore virtual attributes render database retrieval schemas useless. Normally the client requests only the attributes of an entity that it needs at that moment. A datagrid with 3 columns of an attribute with 20 attributes will only fetch 3 attributes from the database. However, when there is a virtual attribute the core pre-fetches all attributes of an object; they might be needed by the microflow of the virtual attribute. I had assumed that it would only re-evaluate a virtual attribute in a datagrid if the attribute was included as one of the columns, but from the above, that is not so. This has caused me to redesign my domain model in a few places to avoid this situation. So, my question is how generalizations fit into this scenario. With this domain model where there is a virtual attribute (Ticket ID) of the Incident entity (which is a specialization of TicketCore), if I have a datagrid of the TicketCore entity, can anyone confirm that the virtual attribute in the Incident specialization will not cause the display of the generalization TicketCore to retrieve all attributes? Thanks Edit: 3 Oct Added another quote from the linked article: So instead of selecting just a few attributes, all attributes are retrieved from the database and sent to the client as soon as a single virtual attribute exists in an entity. Edit 9 Oct: Still looking for confirmation of the behavior from someone at Mendix. I have tried to investigate further myself. Here is a domain model for an object with one virtual attribute (Show_Applications) I turned on JSON logging level Debug in the modeler and displayed a datagrid for this object where the first 5 attributes are displayed as table columns. Here is the log: dsanders REQUEST {"action":"retrieve_by_xpath","params":{"xpath":"//Shared.MenuValues[Shared.MenuValues_MenuTypes='67272519433847865']","schema":{"id":"f8f7e18c-f8cf-4e26-8cff-645f8964c4c7","offset":0,"sort":[["SortOrder","asc"],["Value","asc"]]},"count":true,"aggregates":false},"context":[],"profiledata":{"1df891e04811800":27}} RESULT {"mxobjects":[{"objectType":"Shared.MenuValues","guid":"67553994410558471","attributes":{ "Status":{"value":"Active"}, "Sub_Value_1":{"value":"SR-APR"}, "Value":{"value":"Default Service Request Approval"}, "SortOrder":{"value":"1"}, "Label":{"value":"Default Service Request Approval"}}}, {"objectType":"Shared.MenuValues","guid":"67553994410564468","attributes":{ "Status":{"value":"Active"}, "Sub_Value_1":{"value":"SE-INIT"}, "Value":{"value":"Service Entry Init"}, "SortOrder":{"value":"1"}, "Label":{"value":"Service Entry Init"}}}, {"objectType":"Shared.MenuValues","guid":"67553994410558472","attributes":{ "Status":{"value":"Active"}, "Sub_Value_1":{"value":"TST"}, "Value":{"value":"Test Approval Process"}, "SortOrder":{"value":"2"}, "Label":{"value":"Test Approval Process"}}}, {"objectType":"Shared.MenuValues","guid":"67553994410558473","attributes":{ "Status":{"value":"Active"}, "Sub_Value_1":{"value":"PR-APR"}, "Value":{"value":"Default Problem Approval"}, "SortOrder":{"value":"3"}, "Label":{"value":"Default Problem Approval"}}}, So it looks like only the 5 displayed attributes are retrieved, rather than all 10 attributes. This seems contrary to the quote in the edit of 3 Oct above. It seems to me that Pieter's opinion is correct, and the statement quoted from Michel is misleading. This has great implications for good entity design, so I would still request some definitive description of the behavior from someone at Mendix. Is this statement correct: Furthermore virtual attributes render database retrieval schemas useless. Normally the client requests only the attributes of an entity that it needs at that moment. A datagrid with 3 columns of an attribute with 20 attributes will only fetch 3 attributes from the database. However, when there is a virtual attribute the core pre-fetches all attributes of an object; they might be needed by the microflow of the virtual attribute. So instead of selecting just a few attributes, all attributes are retrieved from the database and sent to the client as soon as a single virtual attribute exists in an entity. Even more confusing. If I change my datagrid to include displaying the virtual attribute, the log only shows it returning a sixth attribute value, not all 10, so I am not convinced the log is showing me what is really going on. Is there a better way to see the SQL queries? RESULT {"mxobjects":[ {"objectType":"Shared.MenuValues","guid":"67553994410558471","attributes":{ "Sub_Value_1":{"value":"SR-APR"}, "Value":{"value":"Default Service Request Approval"}, "SortOrder":{"value":"1"}, "Status":{"value":"Active"}, "Show_Applications":{"value":false,"readonly":true}, "Label":{"value":"Default Service Request Approval"}}},
asked
2 answers
2

The other attributes will only be retrieved when the virtual attribute is actually shown in the grid. You can check this by setting the ConnectionBus_Retrieve lognode to trace and reading the queries it performs on the database.

answered
1

The way i understand your quote is that it only retrieves all attributes when an virtual attribute is shown. Thus as long as you don't show the virtual attribute in the grid it will only fetch the required attributes. However if you make an overview of incidents it will retrieve all attributes of both ticketcore and incident entity for all incidents.

So my guess is that i have to disagree with your statement. An incident overview will retrieve all attributes of the TicketCore entity as they can be used in the

answered