Re: [pgadmin-hackers] Feature test regression failures

Поиск
Список
Период
Сортировка
От Atira Odhner
Тема Re: [pgadmin-hackers] Feature test regression failures
Дата
Msg-id CA+Vc24r1x1nwE0M5N=rO6zr_ozayDMfe6JEi9-EREnRN0Sq8pg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [pgadmin-hackers] Feature test regression failures  (Dave Page <dpage@pgadmin.org>)
Ответы Re: [pgadmin-hackers] Feature test regression failures  (Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
Список pgadmin-hackers

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? 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.

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.

Tira

On Thu, Mar 16, 2017, 6:49 AM Dave Page <dpage@pgadmin.org> wrote:
On Thu, Mar 16, 2017 at 10:39 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Thu, Mar 16, 2017 at 3:55 PM, Dave Page <dpage@pgadmin.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

В списке pgadmin-hackers по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: [pgadmin-hackers] pgAdmin 4 commit: Fix a bunch of file headers.
Следующее
От: Devrim Gündüz
Дата:
Сообщение: Re: [pgadmin-hackers] Last few steps for pgadmin4 on RHEL 6