Re: Feature test regression failures

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>
Cc: Sarah McAlear <smcalear(at)pivotal(dot)io>, Atira Odhner <aodhner(at)pivotal(dot)io>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Feature test regression failures
Date: 2017-03-20 12:03:53
Message-ID: CA+OCxozPteP_TMsjJC5+ZLMpVAAekUedvuDLkwmqkn+UL2DxwA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

On Mon, Mar 20, 2017 at 10:24 AM, Ashesh Vashi
<ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
> On Fri, Mar 17, 2017 at 8:35 PM, Sarah McAlear <smcalear(at)pivotal(dot)io> wrote:
>>
>> Hello,
>>
>> We agree that we should keep an eye on this and the failing feature tests.
>> Our current story touches part of this code, but we won't go into changing
>> the library for now.
>>
>> The patch Tira sent fixes a global variable problem that we found while
>> looking into the code that generates the Tree, that
>> had the potential to load the tree in an infinite loop.
>> Can you apply the patch like this, or would you rather us send it in a
>> separate patch email?
>
> Name of the variable should have been itemData, d (as earlier), as it
> represents the data for the expanding node item.
> And, that is not good enough for resolving the issue.
>
> I've two approaches to resolve the idea.
> 1. Load the nodes (even when the module representing that node is not yet
> loaded)
> Pros:
> - Nodes will be loaded even when the module for the node type is not yet
> loaded.
> Cons:
> - The nodes with modified url (not the default mechanism) may get failed, if
> the module is not yet loaded.
> (NOTE: We've not no nodes with that changes at the moment. so - we can
> safely ignore it.)
> - Operations specific to the nodes will not be honoured until modules is not
> loaded.
>
> 2. Wait for the modules to get loaded before allowing any operations on
> them.
> Pros:
> - All operations will be done on a node only after the respective module is
> loaded.
> Cons:
> - It will block any operations on pgAdmin 4, when the dependent modules are
> being loaded. It can annoy the user.
>
> Please find the patches for both the approaches.
>
> Dave - please take a look at it.

I'll leave you and Tira to figure this one out if you don't mind. My
plate is kinda full at the moment.

I will note though that neither blocking or potential failures are desirable.

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Devrim Gündüz 2017-03-20 12:06:33 Re: Last few steps for pgadmin4 on RHEL 6
Previous Message Dave Page 2017-03-20 11:12:20 Re: Patch submissions