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

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?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: http://www.enterprisedb.com