Re: RM-2519: Show the trigger function under the trigger node.

Hi Dave/Team

On Fri, Oct 9, 2020 at 2:28 PM Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
wrote:

> Hi Dave/Team
>
> On Thu, Oct 8, 2020 at 10:17 PM Akshay Joshi <
> akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>
>>
>>
>> On Thu, 8 Oct, 2020, 20:22 Dave Page, <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi Akshay,
>>>
>>> On Thu, Oct 8, 2020 at 3:43 PM Akshay Joshi <
>>> akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>>>
>>>> Hi Dave/Team
>>>>
>>>> I have started working on RM #2519 to show the trigger function under
>>>> the trigger node. I have made the changes to the code and the trigger
>>>> function is visible under the respective trigger node.
>>>>
>>>> Changes made to achieve this:
>>>>
>>>> - If the trigger function is in the same schema then it works
>>>> absolutely fine, the user can update the properties, view the SQL,
>>>> Statistics, Dependencies, and Dependents.
>>>> - If the trigger function is from the other schema then we need to
>>>> change the schema id as we have a strict API route which adds the schema id
>>>> where the trigger exists. Change has been done and it works.
>>>> - For the trigger function from the other schema, I have added the
>>>> schema-qualified name.
>>>> - Remove the menu options and add a dummy menu "No menu is
>>>> available for this object" when the user selects the trigger function under
>>>> the trigger node. Have to do this because of the different API routes, as
>>>> the object is not available and personally, I feel we should not show the
>>>> context menu to create, delete, drop from there.
>>>>
>>>> *Note:* To remove the menu option completely I have modified the
>>>> *menu.js* and check if the 'showMenu' function is defined. If it is
>>>> defined then call that function and based on the return value, will make
>>>> the decision.
>>>>
>>>> Please refer to the below screenshot for more clarity:
>>>> [image: 2519.png]
>>>>
>>>> Thought/Suggestion?
>>>>
>>>
>>> Yeah, we should not be able to create/drop there, as the trigger must
>>> have the function anyway (you can't define a trigger without a function in
>>> PG, nor can you drop a function that's being used by a trigger).
>>>
>>> However, we should have a working Properties option I would say.
>>>
>>
>> Yes, it is working from properties tab. User can edit from there.
>>
>
> I have tested it today and it works perfectly fine if the trigger
> function is in the same schema, but if we edit properties of the trigger
> function from another schema eventually that object is updated properly,
> but it is not visible under the trigger node. The user needs to refresh the
> trigger node to make it visible again. I am checking it how we can fix this
> but not found any solution yet.
>

I tried a lot to fix the above-mentioned issue but due to our rigid
node structure, it's been difficult to update and show nodes from another
schema. One more example is if there are so many triggers that use the
common trigger function and we provide the update of the trigger function
from the properties tab then we will have to refresh all the triggers uses
that function.

As we already disabled the context menu, I would suggest disabling the
"Edit" button on the properties tab to fix the above-mentioned issue.
According to the actual request, the user wants to see the trigger function
under the trigger node and see the SQL.

If the above looks good I'll commit the code.

>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EDB: http://www.enterprisedb.com
>>>
>>>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
> *pgAdmin Hacker | Sr. Software Architect*
> *EDB Postgres <http://edbpostgres.com>*
>
> *Mobile: +91 976-788-8246*
>

--
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Sr. Software Architect*
*EDB Postgres <http://edbpostgres.com>*

*Mobile: +91 976-788-8246*