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

On Mon, Oct 12, 2020 at 2:36 PM Aditya Toshniwal <
aditya(dot)toshniwal(at)enterprisedb(dot)com> wrote:

> Hi,
>
> On Mon, Oct 12, 2020 at 2:32 PM Akshay Joshi <
> akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>
>>
>>
>> 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.
>>
> You can refer search objects code, it does the same thing - locate the
> object on tree.
>

We need to check the feasibility as this option should be disabled for
the trigger function whose parent is not a trigger. Also, need to modify
the logic of the disabled menu completely. We will have to show only one
menu option "Navigate to function".

>
>>
>>>
>>>
>>> --
>>> 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,
> Aditya Toshniwal
> pgAdmin hacker | Sr. Software Engineer | *edbpostgres.com*
> <http://edbpostgres.com>
> "Don't Complain about Heat, Plant a TREE"
>

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

*Mobile: +91 976-788-8246*