I want to add some computed values to prominent action buttons, that are shown only on detail views. Hopefully they are executed on demand - but who knows - if they are executed on sync its a bad decision. Here is an example of such an display name expression on a button to a filtered view:
concatenate(
"Reports (",
count(
select(Table_Report[ID],
in([Table_Contract],
select(Table_Contract[ID], [Table_Client] = [_THISROW].[ID])
)
)
),
")"
)
Can anybody tell when these display name expressions on prominent action buttons are executed?
Solved! Go to Solution.
@stefanasks wrote:
select(Table_Report[ID], in([Table_Contract], select(Table_Contract[ID], [Table_Client] = [_THISROW].[ID]) ) )
FYI: in case you don't know already, nesting a SELECT() inside another SELECT() is pretty much the worst thing you can do for performance. It's literally brute forcing the answer.
References to the rescue!
Add some reference connections between your tables (they might actually already be there) and you can accomplish the count() much more efficiently.
This will increase the efficiency of the computation to a trivial thing, where you don't really need to consider it anymore.
Hope it helps! Happy Apping!
Your query might be simplified even more:
This would remove all the brute force from the system, massively increasing your efficiency, at the cost of 1 duplicated data field. #WorthIt
Whenever the row is present in a view, even if off-screen.
Your expression is potentially very expensive and could affect battery life if not performance.
That's why ask this question.
So you say that these expressions are computed on render frame, in FPS manner like 60 times per second or at least on scroll screen?
I believe it's on scroll.
@stefanasks wrote:
select(Table_Report[ID], in([Table_Contract], select(Table_Contract[ID], [Table_Client] = [_THISROW].[ID]) ) )
FYI: in case you don't know already, nesting a SELECT() inside another SELECT() is pretty much the worst thing you can do for performance. It's literally brute forcing the answer.
References to the rescue!
Add some reference connections between your tables (they might actually already be there) and you can accomplish the count() much more efficiently.
This will increase the efficiency of the computation to a trivial thing, where you don't really need to consider it anymore.
Hope it helps! Happy Apping!
Thanks, I did not realize that I can use related columns as reference to replace a subselect. So I modified the query:
concatenate(
"Reports (",
count(
select(Table_Report[ID],
in([Table_Contract], [_THISROW].[Related Table_Contracts])
)
),
")"
)
Because in the related columns the subselect is already done, so no need to do it twice.
On the other hand, adding the grand parent ID as reference may blew up the sync process. Imagine 1000 clients with 10 contracts with 100 reports creates 1000 "Related Table_Reports" reference IDs in each client row. What makes 1.000.000 stored reference ids in the client table or about 20MB space only for packedUUID's - if I'm right.
Your query might be simplified even more:
This would remove all the brute force from the system, massively increasing your efficiency, at the cost of 1 duplicated data field. #WorthIt
User | Count |
---|---|
16 | |
11 | |
7 | |
3 | |
2 |