I have multiple database queries in a flow. Only one of them will actually run based on conditions in the flow. I would like to pipe these into one common output, so I do not have to account for multiple queries in my pages.
For example:
If x, then run query_1
If y, then run query_2
If x, then run query_3
output_query = query_1+query_2+query_3
This will make it easier to do things like dmx-repeat:threads="output_query" instead of dmx-repeat:threads="query_1+query_2+query_3"
hey keith,
The queries are SQLite queries. Each has slightly different conditions in the query, but they all produce a similar output of records.
I found the join action which I think may do the trick, but I’m getting an error when trying to run it on the page.
I’m sorry but I don’t know if I understand how this works…
I asked if we are talking about inline flow and if by saying “run query” means that you load a serverconnect (containing that query)
If yes, I’m just thinking of setting a parameter/$_GET (1 or more…) to your serverconnect that indicates which condition is active…
And then in your serveraction structure your query accordingly based on filters with toggle conditions…
Sorry if I didn’t understand correctly.
This is in a Page Flow with mulitple “Capacitor SQLite Query” actions. All of it works, it’s just that on the frontend I have to account for all of the potential outputs from the different queries.
I think the join action may be an option to combine and only have to deal with one “output” after using multiple joins to combine all of the queries.
This is your page flow??
Anyway I can’t understand…
Let’s go with what you say.
Is any of your queries a single record one? (not multiple?)
I found this and maybe is related…
Thanks! No single queries, but not all queries will actually run and return records, so it’s possible that may be causing the error.
Keith you talk about App flow…
I tried to create an App Flow and add a Capacitor SQLite Query but I couldn’t proceed because asks for a connection and I didn’t know what to do… (never used that!)
The Capacitor SQLite Query Builder has the same structure as in the apis? Can you set there Filters and in there Toggle conditions (and use $param to define the conditions)?
(Ignore me if it doesn’t work this way…)
No worries. I think I’ve come up with a better solution and not sure why I haven’t tried this before. I just gave all of the queries the same name. Since only one will actually run, I’m hoping it will work. 
Hahaha, You’re the one!!
“All the roads lead to Rome”
It works…I use this all the time.
I think the way Wappler always changes the name during the Duplicate function made me think they had to be unique. I learn something new everyday. 
It’ll definitely make my code less complex.
This is the preferred method, with the caveat it puts all the onus on you, the dev, to make sure the output schemas of any of your subqueries don’t inadvertently change over time. Wappler takes you “at your word” on the definition of the output schema, so if one of them drifts, execution will go kablooey and may be particularly difficult to diagnose.
I used to wrap all of the queries into one stored procedure that outputs a return based on an input control value, so I could enforce the output schema at the database level (which would immediately error out if I made a mistake during development so I don’t have ghost errors down the line) BUT (and a big BUT) query planners/optimizers DON’T pre-plan statically-nested queries within stored functions as effectively as naked queries, which will rear its head when your dataset grows.
Hence, your route is the best.
I didn’t want to comment as I don’t know app flows well, but this is exactly how I tackle this issue, and use the method a lot (for set values, queries etc.) so I believe you are 100% on the right track here. Looking forward to testing your app out.
