Re: Feature test regression failures

From: Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>
To: Atira Odhner <aodhner(at)pivotal(dot)io>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Feature test regression failures
Date: 2017-03-16 17:39:21
Message-ID: CAG7mmoye-kX8zPV+4E2X+MSEcGbK_HSsw3FpeAXXxYZs+QvbZw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

On Mar 16, 2017 22:32, "Atira Odhner" <aodhner(at)pivotal(dot)io> wrote:

I have seen this issue as well.

Ashesh, this issue is related to the loading of the tree node data, not
loading of code, correct?

Theoritically - Each node may contain code to represent the node url. For
all current nodes follow the function (present in all inherited class for
nodes) to generated URI.

So - indirectly it relies on the individual node code.

Each time the user expands a node triggers an ajax request to fetch the
child nodes. There are probably some performance tradeoffs to loading that
tree up front.

Agree.
That was the reason, we load them only when first parent node (in some
cases grand parent node) is loaded.

But, there are ways to solve this issue without doing that. We could use
callbacks/promises to wait for things to be loaded before rendering the
node in an enabled/expandable state. It might be helpful to use a one-way
data flow redux pattern to manage the state and rendering of the tree nodes.

We're relying on the third party library jquery.acitree for tree operations.
Most operations can be done asynchronous. But - url generation for
individual node is done using callbacks, which can not work in asynchronous
mode.

I am thinking of using the 'require' function within that function, when
that node type is not present in the application at that point of time.
Though - I am still not sure, wheather 'require' works that way, or not.

-- Thanks, Ashesh

Tira

On Thu, Mar 16, 2017, 6:49 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Thu, Mar 16, 2017 at 10:39 AM, Ashesh Vashi <
> ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
>
> On Thu, Mar 16, 2017 at 3:55 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
> Hi Ashesh,
>
> A common theme is emerging from some of the feature test regression
> failures on the Jenkins server. Please see:
>
> https://jenkins.pgadmin.org/job/pgadmin4-master-python27/
> ws/web/regression/screenshots/EDB_Postgres_AS_9.3/
> ConnectsToServerFeatureTest-2017.03.16_10.09.18-Python-2.7.13.png
>
> I've very occasionally seen similar behaviour to this in the past - in
> fact it's part of the reason why we grey out the UI until pgAdmin is
> fully loaded.
>
> Any idea what might be causing it?
>
> This can happen, when the module is not yet loaded for the respective
> node, and it is being expanded.
> Just thinking - shall we load all the javascript in the beginning?
>
>
> That could be a lot of code, especially as the app grows. It may not be an
> issue in the runtime (though, some recent reports would imply otherwise),
> but it almost certainly would be on slower connections to installations
> running in server mode.
>
> There must be a way to ensure the code is loaded before we allow it to be
> used?
>
>
> --
> 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 Atira Odhner 2017-03-16 17:58:58 Re: Patch submissions
Previous Message Devrim Gündüz 2017-03-16 17:15:33 Re: Last few steps for pgadmin4 on RHEL 6