A couple of possible editor bugs

Bugs
1

Hey @Thierry ! A couple of observed things in the editor from my Postgres implementation.

First, I can’t seem to scroll the debugger list of variables (the right column of the debugger). So I have to drag the debug screen to be higher, but if there’s too many variables I can’t make it high enough to see them all.

Second, I know we’ve talked about this before, but is there any way that the labels that appear on the connections when you click ‘show label’ could have a way to tell the text to make a new line? Like the ability to add a “/n” into the label so that it displays with a line break. It would be so so useful to better visually explain what different branches are doing in workflows with lots of conditions. Pretty please!!

Finally, I’m using the Postgres node to insert an entry into a table. The ‘Results’ output doesn’t trigger the workflow to continue any further, I guess because it just receives the success signal and stops. Is this something I can solve with a more clever query perhaps that inserts a line and also returns something from this insertion to the workflow gets a result signal to continue?

Thanks for your help!

EDIT: In deep consultation with ChatGPT, I discovered the magical RETURNING clause. When added to the SQL query it means the ‘Results’ output is triggered by the inserted line.

2

Hi Richard,
We’ve made some changes to the debugger that will fix the scrolling issue and we should be able to make a new release at the end of next week with the updates, I think. We’ve also added to the list the feature you asked for, which is the ability to have labels with line breaks, and that will also be included in the next release.
Finally, given the Postgresql node you mention, you don’t need to add a dummy sql command to get results in the Results output. All you need to do is transmit the data from an input port to continue processing. I’ve attached an example.

https://www.hackeet.com/hackeet/downloads/examples/discourse.postgresql.insert.design

3

Holy moly, this is great news! Thanks for the super fast updates!! And thanks for the example.

I figured out the trick of continuing the input data through the output of the SQL node. The thing I actually needed was the UUID of the thing just created, to use it in a future step. I got that using the RETURNING clause, all good!