UI: View stored procedures in DB menu

[darkwisperer]

Enhancement Request:
Ability to view a list of stored procedures from the left hand DB menu probably similar styling to the DB name just in its list. Similar to how its done in MSSQL management studio

, there would be a collapsed list that would have the results from
select * from information_schema.routines where routine_type = 'PROCEDURE'

Clicking on the name of the SP would open a tab with the SP's code there.

So it needs to be decided if SPs, Functions, Triggers should be in their own collection to separate them from the tables.
-Should we combine the SPs, Functions, Triggers in to a programmability (or some other name) folder and leave the structure the way it is?

• should the tables be in a collection with SPs, Functions, Triggers also being separate collections like SQLdeveloper

I'm not a fan of having a programmability folder/collection, but it can minimize the clutter that is SQLDeveloper. Another option could be a context menu on the DB name that has the option to see the SPs and click the one you with to view...

It is a lot to go over and think about. With direction I would consider helping with this in a couple months

[BornaP]

I'm glad you opened ticket for this issue, because I wanted to do the same 👍

I think structure similar to one in mysql workbench is optimal here. I would keep triggers (and I would add columns) collapsed under each table and views, SP and functions should be in their own collection to separate them from the tables. Something like this:

I'll try to contribute on this in a next couple of days/weeks. Also, @maxcnunes ,could you put 'Enhancement' label to the issue.

[maxcnunes]

Good idea @darkwisperer and @BornaP 👍
I have thought bout it as well in the beginning of the project #24. Some time later I closed that issue to keep the app more "minimalist".

But since there are people interest in this feature I would gladly accept a pull request for it 👯

I prefer the mysql workbench approach. Seems more organized at least. Is important to also think in those DBs that have scheme such as PG (I guess oracle as well). Would be necessary keep all this structure for each scheme. Example:

(Example from https://www.navicat.com/products/navicat-for-postgresql)

I also like the idea of keeping the interface simple and hiding this "advanced" information by default and activating it through some button in the database. But I guess this could have its own issue.

[darkwisperer]

I like the Mysql Workbench approach of putting the triggers under the tables. Perhaps table related synonyms should also be under the table group or in a description page?

@maxcnunes I too like the idea of being able to keep it minimalist, or at least have an option/setting to control what is visible by default. Or on install it asks your preference of either all or minimal then the user can customize from there. Your right this sidebar should be its own issue after a PR has been accepted.

[BornaP]

Hey @maxcnunes ! I took a look at gui part today and here are my thoughts. I was thinking about adding actions and reducers for both views and routines separately, similarly like its done now for tables. Furthermore, maybe it's good idea to extract rendering tables, views and routines in separate component (or components), instead of keeping it all in database-list.jsx . Speaking of UI, here's how I imagined it - under each database we would have submenu consisting of three items - tables, views, routines (SP and functions for mysql/sqlserver, and only functions for postgresql). Tables would, by default, be expanded and shown, while views and routines would be loaded on click. All three would be collapsible.

What do you think? I'd like to hear your opinion before I start with implementation :)

[maxcnunes]

Hi @BornaP. I think you are in the right path. All the solutions you presented sounds a good approach!

[maxcnunes]

Closing this issue since it has already been merged to master.