Hi, I was just wondering if there is potentially any unintended performance impact from referencing many different tables in an app.
Let’s say our app would try to fetch data from 8 different tables all containing a large amount of data. The queries would only be relevant for specific steps in the app.
As I currently understand table records are ALWAYS fetched at all times when any of the defined input criteria change. Correct?
There is currently no way to explicitly trigger the data fetching on-demand.
Doesn’t this create a lot of unnecessary overhead? I mean, if I only need the data at a specific step and the required input parameters will only get populated in due time when reaching this step in the app - theoretically this should fires many rather useless queries nobody is asking for…
Am I missing something? Is the Tulip platform silently monitoring if a query is actually used in a step or not and only run/fetch data if that is indeed the case?
I tought about this problem as well, because our client is facing some performance issues. I think if you could filter queryies multiple times it would solve a lot of performance problems. For example your app only loads in this month data and it is filtered down in each table one more step. This way you don’t need to load in the full data to filter in the tables.
My problem is, that my client (and most others as well) works in two or three shifts.
Currently when I load data trough a query, I can’t filter the table more. I could make a lot of queries in the Records section, but it is hard to look trough currently. This could be improved as well with grouping of queries, and a search bar on top, but this should be another topic on its own.
If the manager want’s to see the three shifts separated, I need table level filtering to achieve this. I think if you could make two step filters (Fetch one week data into a query, and filter for each shift on the table) it would be more a lot more efficient way to load data into apps.
Namely — you have a query Q that you’d like to filter to shifts 1, 2, 3, which is not possible today after creating the query
and you could achieve this today by pre-creating three subqueries, Q1, Q2, Q3, that are appropriately filtered down in advance, but this would make your query list difficult to search through and navigate, and might also have to change as shifts change?
As a result you’re asking for “filterable” queries or dynamic queries that have an additional calculation on load. Is the additional calculation a filter on a particular column in a table, e.g. Shift == 1?
It could be Shift == 1 or specific day and specific shift, so the administrator can see the full weeks data. So my query would be filtered to a specific week and one more time on the tables for each day. I can imagine this being useful in other cases as well.
Creating query groupings and filtering queries would allow similar result to be achieved, because I could create all subqueries and organize them as well.
Perhaps we can set up time or have you come to Office Hours to see if that helps you set up something more scalable? From there we can better identify what’s missing in the current query experience
