Aggregate not returning list length

Good Day

i am trying to determine why my aggregate list is not showing length but only optimized as the result.would anyone be able to provide some assistance?


thanks

The length is number of records actually returned by the query. The platform optimizes queries, and may not return the length, and thus you cannot inspect it while debugging.

If you really need to know the length of the query, you can temporarily assign the list length to a local variable. This way, the platform cannot optimize the length output away.

Sam Rijkers wrote:

The length is number of records actually returned by the query. The platform optimizes queries, and may not return the length, and thus you cannot inspect it while debugging.

If you really need to know the length of the query, you can temporarily assign the list length to a local variable. This way, the platform cannot optimize the length output away.

thank. this raises another question. when i attempt a for each loop on the aggregate, it seems only the current item is being processed any ideas?


Nicholas Belo wrote:

What do you mean only optimized by result? Where are you looking to use the length as well is it on the interface page for a screen? if it is you will call something like: 

SyntaxEditor Code Snippet

GetAggregateByColumnName.List.Length


thanks for the reply, basically what is happening is this:

i have an aggregate in a server action. i run a for each loop for the list result of the aggregate to check each row. however the for each only picks up the current item and no other rows in the list( note if i open the aggregate and plug in the same test values several rows show up) . when i run a debug, i noticed the length showing as optimized along with the count not being evaluated. 

any ideas?


thanks


Solution

People,

It's nice that we have an active community and y'all are trying to help each other, but please only reply if you're really sure what happens here. Unfortunately, that doesn't seem the case and I haven't seen the correct answer to the OP's question.

So, what is really going on here? I'll try to explain to the best of my knowledge. For starters, the Platform optimizes the way queries are handled. First, if the output of the query is bound to a Table Records, it will only fetch the first X rows, where X is the size of the Table Records. Secondly, if it detects that a query is only being used in a For Each (and not, say, assigned to a variable or the like), it will use a database cursor to fetch the records one by one instead of trying to pull the entire output at once.

Both of these optimizations cause the query count to not be available, unless explicitly referenced somewhere. In fact, to get the query count, the Platform executes a seperate count query (basically replacing the selected attributes by a COUNT()), which degrades performance, and is therefore only done when absolutely necessary.

The second optimization causes the debugger to have only the current record available, as all records are simply not yet fetched, and can therefore not be shown.

I hope this answers all questions, if not feel free to ask more.

Solution

No, putting an Aggregate in a Server Action is not a good practice, as the Platform can't optimize the Attributes to fetch. Basically never do that, unless you're fetching only a small set of data!

EDIT: The above was a reaction to a now deleted post that seemed to suggest to return the full Aggregate output from a Server Action. That is indeed not recommended. However, using a query inside an Action and processing the result is fine of course.

Kilian Hekhuis wrote:

No, putting an Aggregate in a Server Action is not a good practice, as the Platform can't optimize the Attributes to fetch. Basically never do that, unless you're fetching only a small set of data!

Kilian I apologize if I didn't understand you correctly, but the Platform does optimize aggregates in a server action pretty much in the same way it optimizes for screens. Only if you return the whole aggregate result as an output of the server action will you lose that optimization.

Hi Afonso,

You are right if you subsequently process the query output. I may have misunderstood, but I thought someone suggested to put just the query in a seperate action (but they have deleted their answer afterwards) and return the full output. That is not recommended. But querying + processing in a Server Action is indeed fine of course, thanks for the correction.