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

On Mon, Oct 12, 2020 at 2:28 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Mon, Oct 12, 2020 at 7:29 AM Akshay Joshi <
> akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>
>> 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.
>>
>
> Hmm, yeah. How much work would it be to have a "Navigate to function"
> context menu option that locates and selects the "real" function in the
> treeview?
>

I have committed the code with the "Edit" button disabled, will analyze
and create a new RM for that.

>
>
> --
> 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*