App testing and aggregations

Hi

When designing apps that utilize queries and aggregations it appears that queries work fine in test mode, but aggregations go back to the original table to make counts, unique value and similar. A simple example is shown below in short video.
This makes reliable testing and demonstration tricky when we have triggers and selection boxes rely on aggregations to work. The use case is making changes to apps directly in the production environment, and use test mode to demonstrate the app functionality prior to releasing for use. We do not want to make real/test entries in the production instance.

Are there any plans to include aggregations fully in the test mode of the app design tool set?

thx and regards
asger

Edit; Realized that this was also raised in 2021: View Table Aggregation Values in Dev Mode. Isnt this a bug?

1 Like

Howdy Asger! :cowboy_hat_face:

I double checked with the Product Team on this. You are right, this has been a long-open topic (both on Community and internally at Tulip!).

There are long term plans in place to revamp aggregations entirely, and because the fix here is not trivial, unfortunately there isn’t a quick win we can put in place in the meantime to address the difference between dev mode and player. I’m sorry I don’t have anything right now to offer, but the team is very aware of this and that long-term solution will address this concern!

1 Like

A similar problem will arise when you have to use any connector function that is calling anything against the table API. This is where the “let’s skip the multi-staged environment” thing becomes a real pain.

Understood that connectors will do the same.
For the first 2 areas we implemented we used the connectors to query data, but since queries and aggregations have become part of the feature set we have stopped using connectors on the platform. We have also had some instances where the connector got a HTTP500 responses at point of running the completion triggers, which we want to avoid by using queries & aggregations.

But since the app export/import feature have been playing a lot of “(restored) (restored)” and aggreation duplicate entries tricks on us, we are actively trying to avoid moving apps between instances if we can avoid it.