1
 Follower
6
 Likes

Don't optimise aggregate lists when looping round them

New

It would be helpful if aggregate outputs weren't optimised when looping round them for debugging purposes.

Take the example below, the aggregate being looped around has multiple results and loops round the code for each of those results, however it is not possible to see the results of the output all at once to compare them and only the current result is shown.  The only way to see the results side by side is to go to the aggregate itself and set test data for the current input for all of the filters.

Given that all of the list results are being used anyway for the loop, it would be better if you could see the entire list in the debug window rather than truncating the results.


Created on 8 Jul (10 days ago)
Comments (9)

I would like to see this too. The problem is, optimizer happens at compile time, so you would need to re-compile to get this to work when you turn the debugger on. Or the code could be give an If under the hood based on whether or not its being debugged and go to a non-optimized version of the query? Either way... as much as I want this, I suspect it will be deemed to be more effort than it is worth. :(

J.Ja

That would be a shame, it is very annoying not being able to view data all the time.  For example my current project has complex data model relationships and I often want to check the results are as expected for varying user inputs in varying scenarios.

It may be that the easiest way to implement this is to have 2 compile options, one that compiles with full optimisation that is used when rolling out apps, and another that has no optimisation at all and is used during design time for debugging purposes.

Agreed... only downside *then* is if someone load tests or performance tests against that debug build... but I've said for a while now that environments marked as non-prod should be handled very differently from prod in a number of ways.

J.Ja

Yes but I think once everyone got used to the 2 different compiles they would easily remember that load/performance tests should only be done on the production compile.

If I there was an option to edit the title of an idea then I would change this one to....

'Have 2 compiles: production with optimisations and development with no optimisations'.

...and for the record, I regularly find the optimisations incredibly frustrating and limiting when trying to check complex code is working correctly as well as for debugging purposes.  So for me this idea is an absolute must have and definitely not just a nice to have.

+1

"...I regularly find the optimisations incredibly frustrating and limiting when trying to check complex code is working correctly..."

I would suggest unit testing for things like that. "Testing with the debugger" is not efficient, repeatable, or scalable. :(

J.Ja

Actually I noticed that there is a unit testing framework in the forge but I haven't checked it out properly yet.

....but I'd still like to be able to see what is going on.  It is annoying to have to loop round to see what data is there or fiddle with test values.

views
60
Followers
1