Re: [pgadmin-hackers] Feature test regression failures - Mailing list pgadmin-hackers

From Dave Page
Subject Re: [pgadmin-hackers] Feature test regression failures
Date
Msg-id CA+OCxozPteP_TMsjJC5+ZLMpVAAekUedvuDLkwmqkn+UL2DxwA@mail.gmail.com
Whole thread Raw
In response to Re: [pgadmin-hackers] Feature test regression failures  (Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
Responses Re: [pgadmin-hackers] Feature test regression failures  (Atira Odhner <aodhner@pivotal.io>)
List pgadmin-hackers
On Mon, Mar 20, 2017 at 10:24 AM, Ashesh Vashi
<ashesh.vashi@enterprisedb.com> wrote:
> On Fri, Mar 17, 2017 at 8:35 PM, Sarah McAlear <smcalear@pivotal.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


pgadmin-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: [pgadmin-hackers] Patch submissions
Next
From: Devrim Gündüz
Date:
Subject: Re: [pgadmin-hackers] Last few steps for pgadmin4 on RHEL 6