Problem with Custom Query step

Hi,
I’m using Wappler 5.5.3, with NodeJS and MySQL and running on Windows 10.

I’m trying to run code that runs well in my Heidi SQL console. When I put it inside a Custom Database step, I get a stack trace.

My SQL statement needs to dynamically generate and then execute a stored procedure. As said, this code runs well in a bare sql interpreter.

I reduced the sql statement to its minimum and I think that the problem is when I the Wappler Custom Database step tries to run the DELIMITER command, which one needs to execute when defining a stored procedure.

This sql code inside the custom query step

no matter which DELIMITER I choose, produces this output

Am I doing something wrong or is this a bug?

Many thanks,

Alex

I’m curious as to why you are dynamically generating a procedure? Why not just run the dynamically generated sql? Are there other use cases for procedures, other than being reusable?

Wappler no longer supports running multiple queries inside custom query step.
At least that has been my observation since I last encountered this error.
So you can’t run this via Wappler.

@Sid,
Thanks Sid.
I just tried to run only this one line:

DELIMITER //

as the body of the Custom Database Query step and Wappler does not want to run it either.

Hi Ken,
The answer to your question is long, so I’ll try to summarize it as follows: the reason I’m trying this approach is driven by the need I have and the fact that what I was trying before did not work.

The Need
Imagine that:
a) there are N types of entities: Ea, Eb, Ec, …, En.
b) I will only know at runtime how many and which entities I’m dealing with
c) I will only know at runtime how these entities are related among them

Once I know points a, b and c, I need to produce a list that shows how these entities are connected. For example (and sorry for my miserable attempt at indenting rows for readability):

Ea1 – Eb2

 Eb2 -- Ec1
 Eb2 -- Ec3
 Eb2 -- Ec5

Ea1 – Eb8

 Eb8 -- Ec1
 Eb8 -- Ec2
 Eb8 -- Ec7

Ea2 – Eb1

 Eb1 -- Ec3
 Eb1 -- Ec4

This is “walking through a relationship tree”, which in general, is solved with a set of nested loops. Points a, b, and c make it necessary to create in real time the SQL statement that needs to be executed.

The original failed approach
I wanted to create the sql statement using Wappler’s text handling abilities. In the end, I’d be “Set(ting the) Value” of a variable called mySQL_statement and then passing that statement by putting it as below in the body of a Database Custom Query step:
{{mySQL_statement}}

I’m doing this successfully for other complex queries.

The problem is that to generate mySQL_statement, because of points a, b, and c above, I need to invoke an API library recursively --i.e., the library calls itself.

Well…since I could not make that recursive API library work properly, I tried generating the LOOPs using SQL itself and cursors. The problem is that cursors need to be inside a stored procedure, and since its content has to be generated dynamically, my new SQL statement has to create the sp, call it, and then drop it. In the code to create the sp I found that the DELIMITER statement, that you need to define a stored procedure, does not work from inside Wappler.

Sorry for the long answer, but since you asked… :slight_smile:

I guess that I’ll have to go back to trying to get the recursive API call work properly. This is something I already spent hours on and I’m not relishing the reattemtp :frowning:

Any fresh idea on how to approach this problem from a different angle will be really appreciated!

Alex

Sorry, I can’t wrap my head around this…but I will tell you how I work.

When I find myself dealing with something this complicated, it USUALLY is an indication that I need to go back and redesign something I’ve put in place already. It sucks to have to refactor, but I see that as part of the process. In other words, the problem lies elsewhere. Again, not always true, but for me, it is often the case. Sometimes it is the db schema itself, and sometimes it is a logic routine that was working fine, but is ultimately triggering this complexity. And with the speed of Wappler features, it is possible new actions are available to help me now – Array actions, grouping, etc. come to mind.

I like to think that this is what “elegant” design/approach is. When even complex processes can be built simply, then we have an elegant solution.

Sorry I can’t support with a tactical solution this time…but sometimes a new strategy helps.

Best of luck finding this–it will feel great when you do!

1 Like