Re: v3.0 release on hold

[Dave Page]

Hi

On Wed, Mar 21, 2018 at 5:52 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hi Dave,
> I think that this Gnome issue should be addressed after the release of
> 3.0. We should create a bug and see the best way to address it after. This
> is my proposal, because I am not 100% sure where this application indicator
> should live.
> If we search the web for application indicators we can see that usually
> these are developed by 3rd parties and is are present at the applications
> repository, so this might be a side project that need to be undertaken, by
> someone in the community or not, but it is not something that should live
> inside our repository as it is not really part of the code source and it is
> more like a Hack for Gnome.
>
> The other issues I believe need to be addressed, specially if they are
> crippling to the application like when you click it does not start, but if
> they are edge cases, we can always release this week and have a new release
> in 2 weeks or something with more fixes to these edge case problems.
>
> I understand that the process of release at this point is a bit cumbersome
> and take a lot of time, but  if we can get more tests around the new and
> old feature we can have more confidence in our code and as a result of that
> we can automate some of the steps in order to generate binaries more
> frequently.
>

The problem is that users of Gnome 3.26 and later don't just lose the tray
icon, pgAdmin will exit with an error entirely. I've tried just removing
that exit() call, but it then takes ages to start, before crashing the
gnome shell and leaving you back at the login prompt.

There are 2 things we need to avoid here:

1) Shipping with a design that is then radically changed yet again in the
next release. This is akin to my concerns about shipping with this runtime
and then replacing it with Electron shortly afterwards.

2) Shipping a product that we know will not work for a potentially large
percentage of Linux users.

Both of those things, particularly the second point, will piss off users
and damage our reputation (which is already somewhat battered following the
performance issues on Windows).



>
> Thanks
> Joao
>
> On Wed, Mar 21, 2018 at 12:54 PM Dave Page  wrote:
>
>> Hi
>>
>> On Wed, Mar 21, 2018 at 4:22 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Hello Dave,
>>> For number 1: https://blogs.gnome.org/aday/2017/08/31/status-icons-
>>> and-gnome/
>>> We might need to build something like: https://itsfoss.com/
>>> best-indicator-applets-ubuntu/
>>> Not sure if it is wise to do it in such a short notice.
>>>
>>
>> Yeah, the problem with the suggested solutions is that they rely on 3rd
>> party extensions that aren't "real" packages for the OS, so we can't just
>> add a dependency on them. Unfortunately I think this is going to cause
>> quite a bit of work to get 3.0 back on track.
>>
>>
>>>
>>> Thanks
>>> Joao
>>>
>>> On Wed, Mar 21, 2018 at 11:38 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On 21 Mar 2018 21:05, "Dave Page"  wrote:

 We've run into a number of unexpected issues with the v3.0 release that
 I think we need to resolve before moving forwards. For the time being, only
 patches critical to fix these issues should be committed.

 I'll try to look at 1, though I do have another deadline I need to
 meet.
 Akshay, can you look at 2 please?
 Fahar is already looking at 3.
 Khushboo, can you look at 4 please?

 Sure.


 Thanks all.

 1) There is no longer a system tray in Gnome 3.26 and later, and thus
 the runtime won't initialise in Fedora 27 and later. We need an alternative
 for this, either a tray replacement that the RPM can depend on, or better
 yet, support whatever it is Gnome expect such apps to use these days.

 2) Starting a second instance of the app bundle on Mac doesn't always
 open a new pgAdmin window as it should. It works fine in the debugger, or
 if you start the app with a command like: "/Applications/pgAdmin\
 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click
 the appbundle or use a command like "open /Applications/pgAdmin\ 4.app"

 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my
 copy, but apparently his is a fresh installation.

 4) On my Windows 7 machine, after running a backup I get no status
 window, and see the following in the logs:

 Traceback (most recent call last):
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
 line 209, in run_wsgi
 execute(self.server.app)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
 line 197, in execute
 application_iter = app(environ, start_response)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\

Re: v3.0 release on hold

[Akshay Joshi]

Hi Dave

On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:

> We've run into a number of unexpected issues with the v3.0 release that I
> think we need to resolve before moving forwards. For the time being, only
> patches critical to fix these issues should be committed.
>
> I'll try to look at 1, though I do have another deadline I need to meet.
> Akshay, can you look at 2 please?
> Fahar is already looking at 3.
> Khushboo, can you look at 4 please?
>
> Thanks all.
>
> 1) There is no longer a system tray in Gnome 3.26 and later, and thus the
> runtime won't initialise in Fedora 27 and later. We need an alternative for
> this, either a tray replacement that the RPM can depend on, or better yet,
> support whatever it is Gnome expect such apps to use these days.
>
> 2) Starting a second instance of the app bundle on Mac doesn't always open
> a new pgAdmin window as it should. It works fine in the debugger, or if you
> start the app with a command like: "/Applications/pgAdmin\
> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
> appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>

  Still working on this, not found any solution yet.

>
> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
> but apparently his is a fresh installation.
>

I have tried on Windows 7 and Windows 8.1 64 bit clean VM (created
using ISO file) and pgAdmin4 is working fine on both. I have given the same
ISO file to Khushboo and she has created VM for both the OS and it is
crashed on her machine (seems strange behaviour), only difference is
version of VMWare fusion. I have 6.0.6 and she has 7.0.1

>
> 4) On my Windows 7 machine, after running a backup I get no status window,
> and see the following in the logs:
>
> Traceback (most recent call last):
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
> line 209, in run_wsgi
> execute(self.server.app)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
> line 197, in execute
> application_iter = app(environ, start_response)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1997, in __call__
> return self.wsgi_app(environ, start_response)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1985, in wsgi_app
> response = self.handle_exception(e)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1540, in handle_exception
> reraise(exc_type, exc_value, tb)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1982, in wsgi_app
> response = self.full_dispatch_request()
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1614, in full_dispatch_request
> rv = self.handle_user_exception(e)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1517, in handle_user_exception
> reraise(exc_type, exc_value, tb)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1612, in full_dispatch_request
> rv = self.dispatch_request()
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1598, in dispatch_request
> return self.view_functions[rule.endpoint](**req.view_args)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask_login.py",
> line 792, in decorated_view
> return func(*args, **kwargs)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\web\pgadmin\misc\bgprocess\__init__.py",
> line 62, in index
> return make_response(response=BatchProcess.list())
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\web\pgadmin\misc\bgprocess\processes.py",
> line 584, in list
> details = desc.details(p.command, args)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\web\pgadmin\tools\backup\__init__.py",
> line 190, in details
> res += html.safe_str(cmd + self.cmd)
> AttributeError: 'BackupMessage' object has no attribute 'cmd'
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



-- 
*Akshay Joshi*

*Sr. Software Architect *



*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*

Re: v3.0 release on hold

[Khushboo Vashi]

Hi Dave,

On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:

> We've run into a number of unexpected issues with the v3.0 release that I
> think we need to resolve before moving forwards. For the time being, only
> patches critical to fix these issues should be committed.
>
> I'll try to look at 1, though I do have another deadline I need to meet.
> Akshay, can you look at 2 please?
> Fahar is already looking at 3.
> Khushboo, can you look at 4 please?
>
> Thanks all.
>
> 1) There is no longer a system tray in Gnome 3.26 and later, and thus the
> runtime won't initialise in Fedora 27 and later. We need an alternative for
> this, either a tray replacement that the RPM can depend on, or better yet,
> support whatever it is Gnome expect such apps to use these days.
>
> 2) Starting a second instance of the app bundle on Mac doesn't always open
> a new pgAdmin window as it should. It works fine in the debugger, or if you
> start the app with a command like: "/Applications/pgAdmin\
> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
> appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>
> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
> but apparently his is a fresh installation.
>
> 4) On my Windows 7 machine, after running a backup I get no status window,
> and see the following in the logs:
>
>
We have tried to reproduce this issue on Windows 7 and Windows 8, but
couldn't reproduce it, It is working fine on both the environments.
Can you please provide the options which you have selected while taking a
backup?

Traceback (most recent call last):
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
> line 209, in run_wsgi
> execute(self.server.app)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
> line 197, in execute
> application_iter = app(environ, start_response)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1997, in __call__
> return self.wsgi_app(environ, start_response)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1985, in wsgi_app
> response = self.handle_exception(e)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1540, in handle_exception
> reraise(exc_type, exc_value, tb)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1982, in wsgi_app
> response = self.full_dispatch_request()
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1614, in full_dispatch_request
> rv = self.handle_user_exception(e)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1517, in handle_user_exception
> reraise(exc_type, exc_value, tb)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1612, in full_dispatch_request
> rv = self.dispatch_request()
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1598, in dispatch_request
> return self.view_functions[rule.endpoint](**req.view_args)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask_login.py",
> line 792, in decorated_view
> return func(*args, **kwargs)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\web\pgadmin\misc\bgprocess\__init__.py",
> line 62, in index
> return make_response(response=BatchProcess.list())
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\web\pgadmin\misc\bgprocess\processes.py",
> line 584, in list
> details = desc.details(p.command, args)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\web\pgadmin\tools\backup\__init__.py",
> line 190, in details
> res += html.safe_str(cmd + self.cmd)
> AttributeError: 'BackupMessage' object has no attribute 'cmd'
>
>
> Thanks,
Khushboo

>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Little patch for Runtime build from Top Level Directory($PGADMIN_SRC) MakeFile

[Rahul Soshte]

how do I resolve those errors in step 4 of the checklist?


On Thu, Mar 22, 2018 at 2:58 PM, Rahul Soshte 
wrote:

> This is my first time trying to make a Patch.
>
> I am using Ubuntu 17.10.
>
> This patch is in reference to the Feature Added by Dave Page
> https://redmine.postgresql.org/issues/1305
>
> I just added code to call makefile in runtime directory(
> $PGADMIN_SRC/runtime/Makefile ) from the top level directory's MakeFile  (
> $PGADMIN_SRC/Makefile )
>
>
> I followed the checklist for submitting a patch sent by Murutuza Zabuawala
>
> <>
> Hello,
>
> Here is the common checklist to follow before sending patch to
> pgAdmin4-hackers group,
>
> 1) Get the latest pull from master branch.
>
> 2) Apply your patch and check if applies successfully on the latest code.
>
> 3) Check for PEP8 issues
> - activate virtual env
> - cd ../web
> - yarn run pep8
>
> 4) Run regression test
> python regression/runtests.py
>
> - To run only UI/feature tests
> python regression/runtests.py --pkg feature_tests
>
> - To run regression test (without UI/Feature tests)
> python regression/runtests.py --exclude feature_tests
>
> 5) Run Jasmine tests
> - activate virtual env
> - cd ../web
> yarn run test:karma-once
>
> 6) Make sure to add or update help docs and screenshot(s) if you have
> added any new feature or changed any existing one.
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
> <===>
>
> But I am facing some issues,
> Step 1,2,3 and 5 had no issues
> But when I tried step 4 it gave some errors
> I executed the following command
>
> *python regression/runtests.py *
>
> I got the following errors:
> 1)The screenshot attached show I wasnt able to connect to the server
> 2) the error ouput on the command line:
> =Running the test cases for 'PostgreSQL 9.4'=
> Traceback (most recent call last):
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 128, in create_database
> server['sslmode']
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 36, in get_db_connection
> sslmode=sslmode
>   File 
> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
> line 130, in connect
> conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
> OperationalError: FATAL:  password authentication failed for user
> "postgres"
> FATAL:  password authentication failed for user "postgres"
>
> Traceback (most recent call last):
>   File "regression/runtests.py", line 350, in 
> server_information = test_utils.create_parent_server_node(server)
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 491, in create_parent_server_node
> server_info['sslmode']
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 36, in get_db_connection
> sslmode=sslmode
>   File 
> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
> line 130, in connect
> conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
> psycopg2.OperationalError: FATAL:  password authentication failed for user
> "postgres"
> FATAL:  password authentication failed for user "postgres"
>
> Traceback (most recent call last):
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 619, in _cleanup
> connection = get_db_server(database["server_id"])
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 593, in get_db_server
> db_name, username, db_password, host, db_port, ssl_mode
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 36, in get_db_connection
> sslmode=sslmode
>   File 
> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
> line 130, in connect
> conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
> OperationalError: FATAL:  password authentication failed for user
> "postgres"
> FATAL:  password authentication failed for user "postgres"
>
> I have no password authentication errors when I am connecting from the
> application.I had also changed password for postgres manually through the
> command line.
>

Re: Little patch for Runtime build from Top Level Directory($PGADMIN_SRC) MakeFile

[Murtuza Zabuawala]

You need to make SERVER_MODE = False in config_local.py in order to run
feature tests.

--
Regards,
Murtuza Zabuawala
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


On Thu, Mar 22, 2018 at 3:00 PM, Rahul Soshte 
wrote:

> how do I resolve those errors in step 4 of the checklist?
>
>
> On Thu, Mar 22, 2018 at 2:58 PM, Rahul Soshte 
> wrote:
>
>> This is my first time trying to make a Patch.
>>
>> I am using Ubuntu 17.10.
>>
>> This patch is in reference to the Feature Added by Dave Page
>> https://redmine.postgresql.org/issues/1305
>>
>> I just added code to call makefile in runtime directory(
>> $PGADMIN_SRC/runtime/Makefile ) from the top level directory's MakeFile  (
>> $PGADMIN_SRC/Makefile )
>>
>>
>> I followed the checklist for submitting a patch sent by Murutuza Zabuawala
>>
>> <>
>> Hello,
>>
>> Here is the common checklist to follow before sending patch to
>> pgAdmin4-hackers group,
>>
>> 1) Get the latest pull from master branch.
>>
>> 2) Apply your patch and check if applies successfully on the latest code.
>>
>> 3) Check for PEP8 issues
>> - activate virtual env
>> - cd ../web
>> - yarn run pep8
>>
>> 4) Run regression test
>> python regression/runtests.py
>>
>> - To run only UI/feature tests
>> python regression/runtests.py --pkg feature_tests
>>
>> - To run regression test (without UI/Feature tests)
>> python regression/runtests.py --exclude feature_tests
>>
>> 5) Run Jasmine tests
>> - activate virtual env
>> - cd ../web
>> yarn run test:karma-once
>>
>> 6) Make sure to add or update help docs and screenshot(s) if you have
>> added any new feature or changed any existing one.
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>> <===>
>>
>> But I am facing some issues,
>> Step 1,2,3 and 5 had no issues
>> But when I tried step 4 it gave some errors
>> I executed the following command
>>
>> *python regression/runtests.py *
>>
>> I got the following errors:
>> 1)The screenshot attached show I wasnt able to connect to the server
>> 2) the error ouput on the command line:
>> =Running the test cases for 'PostgreSQL 9.4'=
>> Traceback (most recent call last):
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 128, in create_database
>> server['sslmode']
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 36, in get_db_connection
>> sslmode=sslmode
>>   File 
>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>> line 130, in connect
>> conn = _connect(dsn, connection_factory=connection_factory,
>> **kwasync)
>> OperationalError: FATAL:  password authentication failed for user
>> "postgres"
>> FATAL:  password authentication failed for user "postgres"
>>
>> Traceback (most recent call last):
>>   File "regression/runtests.py", line 350, in 
>> server_information = test_utils.create_parent_server_node(server)
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 491, in create_parent_server_node
>> server_info['sslmode']
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 36, in get_db_connection
>> sslmode=sslmode
>>   File 
>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>> line 130, in connect
>> conn = _connect(dsn, connection_factory=connection_factory,
>> **kwasync)
>> psycopg2.OperationalError: FATAL:  password authentication failed for
>> user "postgres"
>> FATAL:  password authentication failed for user "postgres"
>>
>> Traceback (most recent call last):
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 619, in _cleanup
>> connection = get_db_server(database["server_id"])
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 593, in get_db_server
>> db_name, username, db_password, host, db_port, ssl_mode
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 36, in get_db_connection
>> sslmode=sslmode
>>   File 
>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>> line 130, in connect
>> conn = _connect(dsn, connection_factory=connection_factory,
>> **kwasync)
>> OperationalError: FATAL:  password authentication failed for user
>> "postgres"
>> FATAL:  password authentication failed for user "postgres"
>>
>> I have no password authentication errors when I am connecting from the
>> application.I had also changed password for postgres manually through the
>> command line.
>>
>
>

Showstopper desktop runtime issue

[Dave Page]

All,

As you know, the 3.0 release is currently on hold as we discovered late
yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
later. This is because the GTK project, and later Gnome, have removed
support for the System Tray on which the new runtime relies.

They have replaced it with a notification mechanism, however this doesn't
really meet our needs as what we want is a place (the tray icon) to attach
a menu to control the pgAdmin server; we don't really use notifications as
such.

I see a number of possible ways around this:

1) Return to the previous runtime. I think this is at best a short-term
solution, as the re-visited Annulen version of the QtWebKit seems to be
getting little attention at the moment, and this would re-introduce many
known bugs caused by WebKit.

2) Re-work the current runtime code to remove the tray icon, and utilise
desktop/start menu items to signal the running instance to show the logs,
configure the server, exit etc. This should work, but will be kinda klunky.

3) Put effort into polishing Joao's Electron based runtime. This might be a
good long term solution as it would remove the need to have any C++ code of
our own, and might allow us to use Electron's update mechanism to do
software updates. The downsides are that we would lose support for dockable
tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
currently support.

Thoughts and comments please folks? How do we want to proceed? I'm
currently leaning towards 2 for v3, and possibly moving to 3 in the long
term.

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

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

Re: v3.0 release on hold

[Dave Page]

Hi

On Thu, Mar 22, 2018 at 9:25 AM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi Dave,
>
> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:
>
>> We've run into a number of unexpected issues with the v3.0 release that I
>> think we need to resolve before moving forwards. For the time being, only
>> patches critical to fix these issues should be committed.
>>
>> I'll try to look at 1, though I do have another deadline I need to meet.
>> Akshay, can you look at 2 please?
>> Fahar is already looking at 3.
>> Khushboo, can you look at 4 please?
>>
>> Thanks all.
>>
>> 1) There is no longer a system tray in Gnome 3.26 and later, and thus the
>> runtime won't initialise in Fedora 27 and later. We need an alternative for
>> this, either a tray replacement that the RPM can depend on, or better yet,
>> support whatever it is Gnome expect such apps to use these days.
>>
>> 2) Starting a second instance of the app bundle on Mac doesn't always
>> open a new pgAdmin window as it should. It works fine in the debugger, or
>> if you start the app with a command like: "/Applications/pgAdmin\
>> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
>> appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>>
>> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
>> but apparently his is a fresh installation.
>>
>> 4) On my Windows 7 machine, after running a backup I get no status
>> window, and see the following in the logs:
>>
>>
> We have tried to reproduce this issue on Windows 7 and Windows 8, but
> couldn't reproduce it, It is working fine on both the environments.
> Can you please provide the options which you have selected while taking a
> backup?
>

They were all the default options - I just selected a database,
right-clicked to select backup, and entered a filename.


>
> Traceback (most recent call last):
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>> line 209, in run_wsgi
>> execute(self.server.app)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>> line 197, in execute
>> application_iter = app(environ, start_response)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1997, in __call__
>> return self.wsgi_app(environ, start_response)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1985, in wsgi_app
>> response = self.handle_exception(e)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1540, in handle_exception
>> reraise(exc_type, exc_value, tb)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1982, in wsgi_app
>> response = self.full_dispatch_request()
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1614, in full_dispatch_request
>> rv = self.handle_user_exception(e)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1517, in handle_user_exception
>> reraise(exc_type, exc_value, tb)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1612, in full_dispatch_request
>> rv = self.dispatch_request()
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1598, in dispatch_request
>> return self.view_functions[rule.endpoint](**req.view_args)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask_login.py",
>> line 792, in decorated_view
>> return func(*args, **kwargs)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\web\pgadmin\misc\bgprocess\__init__.py",
>> line 62, in index
>> return make_response(response=BatchProcess.list())
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\web\pgadmin\misc\bgprocess\processes.py",
>> line 584, in list
>> details = desc.details(p.command, args)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\web\pgadmin\tools\backup\__init__.py",
>> line 190, in details
>> res += html.safe_str(cmd + self.cmd)
>> AttributeError: 'BackupMessage' object has no attribute 'cmd'
>>
>>
>> Thanks,
> Khushboo
>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>


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

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

Re: v3.0 release on hold

[Dave Page]

Hi

On Thu, Mar 22, 2018 at 9:21 AM, Akshay Joshi  wrote:

> Hi Dave
>
> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:
>
>> We've run into a number of unexpected issues with the v3.0 release that I
>> think we need to resolve before moving forwards. For the time being, only
>> patches critical to fix these issues should be committed.
>>
>> I'll try to look at 1, though I do have another deadline I need to meet.
>> Akshay, can you look at 2 please?
>> Fahar is already looking at 3.
>> Khushboo, can you look at 4 please?
>>
>> Thanks all.
>>
>> 1) There is no longer a system tray in Gnome 3.26 and later, and thus the
>> runtime won't initialise in Fedora 27 and later. We need an alternative for
>> this, either a tray replacement that the RPM can depend on, or better yet,
>> support whatever it is Gnome expect such apps to use these days.
>>
>> 2) Starting a second instance of the app bundle on Mac doesn't always
>> open a new pgAdmin window as it should. It works fine in the debugger, or
>> if you start the app with a command like: "/Applications/pgAdmin\
>> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
>> appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>>
>
>   Still working on this, not found any solution yet.
>
>>
>> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
>> but apparently his is a fresh installation.
>>
>
> I have tried on Windows 7 and Windows 8.1 64 bit clean VM (created
> using ISO file) and pgAdmin4 is working fine on both. I have given the same
> ISO file to Khushboo and she has created VM for both the OS and it is
> crashed on her machine (seems strange behaviour), only difference is
> version of VMWare fusion. I have 6.0.6 and she has 7.0.1
>

Is it possible that on one virtual machine VMware Tools were installed, but
not on the other? I ask because I believe they install a version of the
MSVC runtime.


>
>> 4) On my Windows 7 machine, after running a backup I get no status
>> window, and see the following in the logs:
>>
>> Traceback (most recent call last):
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>> line 209, in run_wsgi
>> execute(self.server.app)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>> line 197, in execute
>> application_iter = app(environ, start_response)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1997, in __call__
>> return self.wsgi_app(environ, start_response)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1985, in wsgi_app
>> response = self.handle_exception(e)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1540, in handle_exception
>> reraise(exc_type, exc_value, tb)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1982, in wsgi_app
>> response = self.full_dispatch_request()
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1614, in full_dispatch_request
>> rv = self.handle_user_exception(e)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1517, in handle_user_exception
>> reraise(exc_type, exc_value, tb)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1612, in full_dispatch_request
>> rv = self.dispatch_request()
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1598, in dispatch_request
>> return self.view_functions[rule.endpoint](**req.view_args)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask_login.py",
>> line 792, in decorated_view
>> return func(*args, **kwargs)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\web\pgadmin\misc\bgprocess\__init__.py",
>> line 62, in index
>> return make_response(response=BatchProcess.list())
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\web\pgadmin\misc\bgprocess\processes.py",
>> line 584, in list
>> details = desc.details(p.command, args)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\web\pgadmin\tools\backup\__init__.py",
>> line 190, in details
>> res += html.safe_str(cmd + self.cmd)
>> AttributeError: 'BackupMessage' object has no attribute 'cmd'
>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
>
> --
> *Akshay Joshi*
>
> *Sr. Software Architect *
>
>
>
> *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 976-788-8246
> <+91%2097678%2088246>*
>



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

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

Re: v3.0 release on hold

[Khushboo Vashi]

On Thu, Mar 22, 2018 at 3:20 PM, Dave Page  wrote:

> Hi
>
> On Thu, Mar 22, 2018 at 9:25 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:
>>
>>> We've run into a number of unexpected issues with the v3.0 release that
>>> I think we need to resolve before moving forwards. For the time being, only
>>> patches critical to fix these issues should be committed.
>>>
>>> I'll try to look at 1, though I do have another deadline I need to meet.
>>> Akshay, can you look at 2 please?
>>> Fahar is already looking at 3.
>>> Khushboo, can you look at 4 please?
>>>
>>> Thanks all.
>>>
>>> 1) There is no longer a system tray in Gnome 3.26 and later, and thus
>>> the runtime won't initialise in Fedora 27 and later. We need an alternative
>>> for this, either a tray replacement that the RPM can depend on, or better
>>> yet, support whatever it is Gnome expect such apps to use these days.
>>>
>>> 2) Starting a second instance of the app bundle on Mac doesn't always
>>> open a new pgAdmin window as it should. It works fine in the debugger, or
>>> if you start the app with a command like: "/Applications/pgAdmin\
>>> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
>>> appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>>>
>>> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
>>> but apparently his is a fresh installation.
>>>
>>> 4) On my Windows 7 machine, after running a backup I get no status
>>> window, and see the following in the logs:
>>>
>>>
>> We have tried to reproduce this issue on Windows 7 and Windows 8, but
>> couldn't reproduce it, It is working fine on both the environments.
>> Can you please provide the options which you have selected while taking a
>> backup?
>>
>
> They were all the default options - I just selected a database,
> right-clicked to select backup, and entered a filename.
>
>
With the default options, it is working fine.

>
>> Traceback (most recent call last):
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>>> line 209, in run_wsgi
>>> execute(self.server.app)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>>> line 197, in execute
>>> application_iter = app(environ, start_response)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1997, in __call__
>>> return self.wsgi_app(environ, start_response)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1985, in wsgi_app
>>> response = self.handle_exception(e)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1540, in handle_exception
>>> reraise(exc_type, exc_value, tb)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1982, in wsgi_app
>>> response = self.full_dispatch_request()
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1614, in full_dispatch_request
>>> rv = self.handle_user_exception(e)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1517, in handle_user_exception
>>> reraise(exc_type, exc_value, tb)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1612, in full_dispatch_request
>>> rv = self.dispatch_request()
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1598, in dispatch_request
>>> return self.view_functions[rule.endpoint](**req.view_args)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask_login.py",
>>> line 792, in decorated_view
>>> return func(*args, **kwargs)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\web\pgadmin\misc\bgprocess\__init__.py",
>>> line 62, in index
>>> return make_response(response=BatchProcess.list())
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\web\pgadmin\misc\bgprocess\processes.py",
>>> line 584, in list
>>> details = desc.details(p.command, args)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\web\pgadmin\tools\backup\__init__.py",
>>> line 190, in details
>>> res += html.safe_str(cmd + self.cmd)
>>> AttributeError: 'BackupMessage' object has no attribute 'cmd'
>>>
>>>
>>> Thanks,
>> Khushboo
>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Showstopper desktop runtime issue

[Akshay Joshi]

On Thu, Mar 22, 2018 at 3:19 PM, Dave Page  wrote:

> All,
>
> As you know, the 3.0 release is currently on hold as we discovered late
> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
> later. This is because the GTK project, and later Gnome, have removed
> support for the System Tray on which the new runtime relies.
>
> They have replaced it with a notification mechanism, however this doesn't
> really meet our needs as what we want is a place (the tray icon) to attach
> a menu to control the pgAdmin server; we don't really use notifications as
> such.
>
> I see a number of possible ways around this:
>
> 1) Return to the previous runtime. I think this is at best a short-term
> solution, as the re-visited Annulen version of the QtWebKit seems to be
> getting little attention at the moment, and this would re-introduce many
> known bugs caused by WebKit.
>
> 2) Re-work the current runtime code to remove the tray icon, and utilise
> desktop/start menu items to signal the running instance to show the logs,
> configure the server, exit etc. This should work, but will be kinda klunky.
>
> 3) Put effort into polishing Joao's Electron based runtime. This might be
> a good long term solution as it would remove the need to have any C++ code
> of our own, and might allow us to use Electron's update mechanism to do
> software updates. The downsides are that we would lose support for dockable
> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
> currently support.
>
> Thoughts and comments please folks? How do we want to proceed? I'm
> currently leaning towards 2 for v3, and possibly moving to 3 in the long
> term.
>

Option 2 seems good to me.

>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



-- 
*Akshay Joshi*

*Sr. Software Architect *



*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*

Re: v3.0 release on hold

[Dave Page]

On Thu, Mar 22, 2018 at 9:58 AM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Thu, Mar 22, 2018 at 3:20 PM, Dave Page  wrote:
>
>> Hi
>>
>> On Thu, Mar 22, 2018 at 9:25 AM, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:
>>>
 We've run into a number of unexpected issues with the v3.0 release that
 I think we need to resolve before moving forwards. For the time being, only
 patches critical to fix these issues should be committed.

 I'll try to look at 1, though I do have another deadline I need to
 meet.
 Akshay, can you look at 2 please?
 Fahar is already looking at 3.
 Khushboo, can you look at 4 please?

 Thanks all.

 1) There is no longer a system tray in Gnome 3.26 and later, and thus
 the runtime won't initialise in Fedora 27 and later. We need an alternative
 for this, either a tray replacement that the RPM can depend on, or better
 yet, support whatever it is Gnome expect such apps to use these days.

 2) Starting a second instance of the app bundle on Mac doesn't always
 open a new pgAdmin window as it should. It works fine in the debugger, or
 if you start the app with a command like: "/Applications/pgAdmin\
 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click
 the appbundle or use a command like "open /Applications/pgAdmin\ 4.app"

 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my
 copy, but apparently his is a fresh installation.

 4) On my Windows 7 machine, after running a backup I get no status
 window, and see the following in the logs:


>>> We have tried to reproduce this issue on Windows 7 and Windows 8, but
>>> couldn't reproduce it, It is working fine on both the environments.
>>> Can you please provide the options which you have selected while taking
>>> a backup?
>>>
>>
>> They were all the default options - I just selected a database,
>> right-clicked to select backup, and entered a filename.
>>
>>
> With the default options, it is working fine.
>

Can you see any  way in which the exception below could conceivably happen?
Perhaps if run on a system that has process logs from an older version of
pgAdmin?


>
>>> Traceback (most recent call last):
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
 line 209, in run_wsgi
 execute(self.server.app)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
 line 197, in execute
 application_iter = app(environ, start_response)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1997, in __call__
 return self.wsgi_app(environ, start_response)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1985, in wsgi_app
 response = self.handle_exception(e)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1540, in handle_exception
 reraise(exc_type, exc_value, tb)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1982, in wsgi_app
 response = self.full_dispatch_request()
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1614, in full_dispatch_request
 rv = self.handle_user_exception(e)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1517, in handle_user_exception
 reraise(exc_type, exc_value, tb)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1612, in full_dispatch_request
 rv = self.dispatch_request()
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1598, in dispatch_request
 return self.view_functions[rule.endpoint](**req.view_args)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask_login.py",
 line 792, in decorated_view
 return func(*args, **kwargs)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\web\pgadmin\misc\bgprocess\__init__.py",
 line 62, in index
 return make_response(response=BatchProcess.list())
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\web\pgadmin\misc\bgprocess\processes.py",
 line 584, in list
 details = desc.details(p.command, args)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\web\pgadmin\tools\backup\__init__.py",
 line 190, in details
 res += html.safe_str(cmd + self.cmd)
 AttributeError: 'BackupMessage' object has no attribute 'cmd'


 Thanks,
>>> Khushboo
>>>

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

Re: Showstopper desktop runtime issue

[Neel Patel]

Hi,

On Thu, Mar 22, 2018 at 3:19 PM, Dave Page  wrote:

> All,
>
> As you know, the 3.0 release is currently on hold as we discovered late
> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
> later. This is because the GTK project, and later Gnome, have removed
> support for the System Tray on which the new runtime relies.
>
> They have replaced it with a notification mechanism, however this doesn't
> really meet our needs as what we want is a place (the tray icon) to attach
> a menu to control the pgAdmin server; we don't really use notifications as
> such.
>
> I see a number of possible ways around this:
>
> 1) Return to the previous runtime. I think this is at best a short-term
> solution, as the re-visited Annulen version of the QtWebKit seems to be
> getting little attention at the moment, and this would re-introduce many
> known bugs caused by WebKit.
>
> 2) Re-work the current runtime code to remove the tray icon, and utilise
> desktop/start menu items to signal the running instance to show the logs,
> configure the server, exit etc. This should work, but will be kinda klunky.
>
> 3) Put effort into polishing Joao's Electron based runtime. This might be
> a good long term solution as it would remove the need to have any C++ code
> of our own, and might allow us to use Electron's update mechanism to do
> software updates. The downsides are that we would lose support for dockable
> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
> currently support.
>
> Thoughts and comments please folks? How do we want to proceed? I'm
> currently leaning towards 2 for v3, and possibly moving to 3 in the long
> term.
>

As per our previous efforts on Qt's web rendering framework, I am not in
favor of adding it again as it add lots of dependency and complexity.
I would suggest to go for option 2 - To re-work the current runtime code
and find out how to get already running instance of pgadmin4.


>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Showstopper desktop runtime issue

[Dave Page]

On Thu, Mar 22, 2018 at 10:19 AM, Neel Patel 
wrote:

> Hi,
>
> On Thu, Mar 22, 2018 at 3:19 PM, Dave Page  wrote:
>
>> All,
>>
>> As you know, the 3.0 release is currently on hold as we discovered late
>> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
>> later. This is because the GTK project, and later Gnome, have removed
>> support for the System Tray on which the new runtime relies.
>>
>> They have replaced it with a notification mechanism, however this doesn't
>> really meet our needs as what we want is a place (the tray icon) to attach
>> a menu to control the pgAdmin server; we don't really use notifications as
>> such.
>>
>> I see a number of possible ways around this:
>>
>> 1) Return to the previous runtime. I think this is at best a short-term
>> solution, as the re-visited Annulen version of the QtWebKit seems to be
>> getting little attention at the moment, and this would re-introduce many
>> known bugs caused by WebKit.
>>
>> 2) Re-work the current runtime code to remove the tray icon, and utilise
>> desktop/start menu items to signal the running instance to show the logs,
>> configure the server, exit etc. This should work, but will be kinda klunky.
>>
>> 3) Put effort into polishing Joao's Electron based runtime. This might be
>> a good long term solution as it would remove the need to have any C++ code
>> of our own, and might allow us to use Electron's update mechanism to do
>> software updates. The downsides are that we would lose support for dockable
>> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
>> currently support.
>>
>> Thoughts and comments please folks? How do we want to proceed? I'm
>> currently leaning towards 2 for v3, and possibly moving to 3 in the long
>> term.
>>
>
> As per our previous efforts on Qt's web rendering framework, I am not in
> favor of adding it again as it add lots of dependency and complexity.
> I would suggest to go for option 2 - To re-work the current runtime code
> and find out how to get already running instance of pgadmin4.
>

We have a shared memory interlock as well as temp/lock files that encode
the executable path into their name that handles that already, though it
doesn't seem to be working quite as expected when you run from a Mac
Appbundle (which Akshay is working on). The issue would be how we signal
the running instance and tell it to do something, e.g. exit.

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

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

Fwd: Little patch for Runtime build from Top Level Directory($PGADMIN_SRC) MakeFile

[Rahul Soshte]

-- Forwarded message --
From: Rahul Soshte 
Date: Thu, Mar 22, 2018 at 4:01 PM
Subject: Re: Little patch for Runtime build from Top Level
Directory($PGADMIN_SRC) MakeFile
To: Murtuza Zabuawala 


I am still getting the same error even when I did SERVER_MODE = False.

On Thu, Mar 22, 2018 at 3:05 PM, Murtuza Zabuawala  wrote:

> You need to make SERVER_MODE = False in config_local.py in order to run
> feature tests.
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> On Thu, Mar 22, 2018 at 3:00 PM, Rahul Soshte 
> wrote:
>
>> how do I resolve those errors in step 4 of the checklist?
>>
>>
>> On Thu, Mar 22, 2018 at 2:58 PM, Rahul Soshte 
>> wrote:
>>
>>> This is my first time trying to make a Patch.
>>>
>>> I am using Ubuntu 17.10.
>>>
>>> This patch is in reference to the Feature Added by Dave Page
>>> https://redmine.postgresql.org/issues/1305
>>>
>>> I just added code to call makefile in runtime directory(
>>> $PGADMIN_SRC/runtime/Makefile ) from the top level directory's MakeFile  (
>>> $PGADMIN_SRC/Makefile )
>>>
>>>
>>> I followed the checklist for submitting a patch sent by Murutuza
>>> Zabuawala
>>>
>>> <>
>>> Hello,
>>>
>>> Here is the common checklist to follow before sending patch to
>>> pgAdmin4-hackers group,
>>>
>>> 1) Get the latest pull from master branch.
>>>
>>> 2) Apply your patch and check if applies successfully on the latest code.
>>>
>>> 3) Check for PEP8 issues
>>> - activate virtual env
>>> - cd ../web
>>> - yarn run pep8
>>>
>>> 4) Run regression test
>>> python regression/runtests.py
>>>
>>> - To run only UI/feature tests
>>> python regression/runtests.py --pkg feature_tests
>>>
>>> - To run regression test (without UI/Feature tests)
>>> python regression/runtests.py --exclude feature_tests
>>>
>>> 5) Run Jasmine tests
>>> - activate virtual env
>>> - cd ../web
>>> yarn run test:karma-once
>>>
>>> 6) Make sure to add or update help docs and screenshot(s) if you have
>>> added any new feature or changed any existing one.
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>> <===>
>>>
>>> But I am facing some issues,
>>> Step 1,2,3 and 5 had no issues
>>> But when I tried step 4 it gave some errors
>>> I executed the following command
>>>
>>> *python regression/runtests.py *
>>>
>>> I got the following errors:
>>> 1)The screenshot attached show I wasnt able to connect to the server
>>> 2) the error ouput on the command line:
>>> =Running the test cases for 'PostgreSQL 9.4'=
>>> Traceback (most recent call last):
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 128, in create_database
>>> server['sslmode']
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 36, in get_db_connection
>>> sslmode=sslmode
>>>   File 
>>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>>> line 130, in connect
>>> conn = _connect(dsn, connection_factory=connection_factory,
>>> **kwasync)
>>> OperationalError: FATAL:  password authentication failed for user
>>> "postgres"
>>> FATAL:  password authentication failed for user "postgres"
>>>
>>> Traceback (most recent call last):
>>>   File "regression/runtests.py", line 350, in 
>>> server_information = test_utils.create_parent_server_node(server)
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 491, in create_parent_server_node
>>> server_info['sslmode']
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 36, in get_db_connection
>>> sslmode=sslmode
>>>   File 
>>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>>> line 130, in connect
>>> conn = _connect(dsn, connection_factory=connection_factory,
>>> **kwasync)
>>> psycopg2.OperationalError: FATAL:  password authentication failed for
>>> user "postgres"
>>> FATAL:  password authentication failed for user "postgres"
>>>
>>> Traceback (most recent call last):
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 619, in _cleanup
>>> connection = get_db_server(database["server_id"])
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 593, in get_db_server
>>> db_name, username, db_password, host, db_port, ssl_mode
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 36, in get_db_connection
>>> sslmode=sslmode
>>>   File 
>>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>>> line 130, in connect
>>> conn = _

Re: Little patch for Runtime build from Top Level Directory($PGADMIN_SRC) MakeFile

[Rahul Soshte]

Although I have postgresql-9.6 it is showing
--
--
Running the test cases for 'PostgreSQL 9.4'

On Thu, Mar 22, 2018 at 4:01 PM, Rahul Soshte 
wrote:

>
> -- Forwarded message --
> From: Rahul Soshte 
> Date: Thu, Mar 22, 2018 at 4:01 PM
> Subject: Re: Little patch for Runtime build from Top Level
> Directory($PGADMIN_SRC) MakeFile
> To: Murtuza Zabuawala 
>
>
> I am still getting the same error even when I did SERVER_MODE = False.
>
> On Thu, Mar 22, 2018 at 3:05 PM, Murtuza Zabuawala <
> murtuza.zabuaw...@enterprisedb.com> wrote:
>
>> You need to make SERVER_MODE = False in config_local.py in order to run
>> feature tests.
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> On Thu, Mar 22, 2018 at 3:00 PM, Rahul Soshte 
>> wrote:
>>
>>> how do I resolve those errors in step 4 of the checklist?
>>>
>>>
>>> On Thu, Mar 22, 2018 at 2:58 PM, Rahul Soshte 
>>> wrote:
>>>
 This is my first time trying to make a Patch.

 I am using Ubuntu 17.10.

 This patch is in reference to the Feature Added by Dave Page
 https://redmine.postgresql.org/issues/1305

 I just added code to call makefile in runtime directory(
 $PGADMIN_SRC/runtime/Makefile ) from the top level directory's MakeFile  (
 $PGADMIN_SRC/Makefile )


 I followed the checklist for submitting a patch sent by Murutuza
 Zabuawala

 <>
 Hello,

 Here is the common checklist to follow before sending patch to
 pgAdmin4-hackers group,

 1) Get the latest pull from master branch.

 2) Apply your patch and check if applies successfully on the latest
 code.

 3) Check for PEP8 issues
 - activate virtual env
 - cd ../web
 - yarn run pep8

 4) Run regression test
 python regression/runtests.py

 - To run only UI/feature tests
 python regression/runtests.py --pkg feature_tests

 - To run regression test (without UI/Feature tests)
 python regression/runtests.py --exclude feature_tests

 5) Run Jasmine tests
 - activate virtual env
 - cd ../web
 yarn run test:karma-once

 6) Make sure to add or update help docs and screenshot(s) if you have
 added any new feature or changed any existing one.

 --
 Regards,
 Murtuza Zabuawala
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company
 <===>

 But I am facing some issues,
 Step 1,2,3 and 5 had no issues
 But when I tried step 4 it gave some errors
 I executed the following command

 *python regression/runtests.py *

 I got the following errors:
 1)The screenshot attached show I wasnt able to connect to the server
 2) the error ouput on the command line:
 =Running the test cases for 'PostgreSQL 9.4'=
 Traceback (most recent call last):
   File 
 "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
 line 128, in create_database
 server['sslmode']
   File 
 "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
 line 36, in get_db_connection
 sslmode=sslmode
   File 
 "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
 line 130, in connect
 conn = _connect(dsn, connection_factory=connection_factory,
 **kwasync)
 OperationalError: FATAL:  password authentication failed for user
 "postgres"
 FATAL:  password authentication failed for user "postgres"

 Traceback (most recent call last):
   File "regression/runtests.py", line 350, in 
 server_information = test_utils.create_parent_server_node(server)
   File 
 "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
 line 491, in create_parent_server_node
 server_info['sslmode']
   File 
 "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
 line 36, in get_db_connection
 sslmode=sslmode
   File 
 "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
 line 130, in connect
 conn = _connect(dsn, connection_factory=connection_factory,
 **kwasync)
 psycopg2.OperationalError: FATAL:  password authentication failed for
 user "postgres"
 FATAL:  password authentication failed for user "postgres"

 Traceback (most recent call last):
   File 
 "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
 line 619, in _cleanup
 connection = get_db_server(database["server_id"])
   File 
 "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
 line 593, in get_db_server
 db_n

Re: Showstopper desktop runtime issue

[Murtuza Zabuawala]

On Thu, Mar 22, 2018 at 3:19 PM, Dave Page  wrote:

> All,
>
> As you know, the 3.0 release is currently on hold as we discovered late
> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
> later. This is because the GTK project, and later Gnome, have removed
> support for the System Tray on which the new runtime relies.
>
> They have replaced it with a notification mechanism, however this doesn't
> really meet our needs as what we want is a place (the tray icon) to attach
> a menu to control the pgAdmin server; we don't really use notifications as
> such.
>
> I see a number of possible ways around this:
>
> 1) Return to the previous runtime. I think this is at best a short-term
> solution, as the re-visited Annulen version of the QtWebKit seems to be
> getting little attention at the moment, and this would re-introduce many
> known bugs caused by WebKit.
>
​I would not prefer going back after seeing QtWebkit & QtWebEngine issues
in the past.​


>
> 2) Re-work the current runtime code to remove the tray icon, and utilise
> desktop/start menu items to signal the running instance to show the logs,
> configure the server, exit etc. This should work, but will be kinda klunky.
>
​+1​


>
> 3) Put effort into polishing Joao's Electron based runtime. This might be
> a good long term solution as it would remove the need to have any C++ code
> of our own, and might allow us to use Electron's update mechanism to do
> software updates. The downsides are that we would lose support for dockable
> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
> currently support.
>
​This is a good alternative but there are some downside of Electron,
- It takes longer to start application
- High cpu & ram usage (I have used Slack, Atom & VSCode all of them used
Electron)


> Thoughts and comments please folks? How do we want to proceed? I'm
> currently leaning towards 2 for v3, and possibly moving to 3 in the long
> term.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Little patch for Runtime build from Top Level Directory($PGADMIN_SRC) MakeFile

[Rahul Soshte]

Although I have postgresql-9.6 it is showing-Running the test cases for
'PostgreSQL 9.4'


On Thu, Mar 22, 2018 at 4:17 PM, Rahul Soshte 
wrote:

> Although I have postgresql-9.6 it is showing
> --
> --
> Running the test cases for 'PostgreSQL 9.4'
>
> On Thu, Mar 22, 2018 at 4:01 PM, Rahul Soshte 
> wrote:
>
>>
>> -- Forwarded message --
>> From: Rahul Soshte 
>> Date: Thu, Mar 22, 2018 at 4:01 PM
>> Subject: Re: Little patch for Runtime build from Top Level
>> Directory($PGADMIN_SRC) MakeFile
>> To: Murtuza Zabuawala 
>>
>>
>> I am still getting the same error even when I did SERVER_MODE = False.
>>
>> On Thu, Mar 22, 2018 at 3:05 PM, Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> You need to make SERVER_MODE = False in config_local.py in order to run
>>> feature tests.
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>>
>>> On Thu, Mar 22, 2018 at 3:00 PM, Rahul Soshte 
>>> wrote:
>>>
 how do I resolve those errors in step 4 of the checklist?


 On Thu, Mar 22, 2018 at 2:58 PM, Rahul Soshte >>> > wrote:

> This is my first time trying to make a Patch.
>
> I am using Ubuntu 17.10.
>
> This patch is in reference to the Feature Added by Dave Page
> https://redmine.postgresql.org/issues/1305
>
> I just added code to call makefile in runtime directory(
> $PGADMIN_SRC/runtime/Makefile ) from the top level directory's MakeFile  (
> $PGADMIN_SRC/Makefile )
>
>
> I followed the checklist for submitting a patch sent by Murutuza
> Zabuawala
>
> <>
> Hello,
>
> Here is the common checklist to follow before sending patch to
> pgAdmin4-hackers group,
>
> 1) Get the latest pull from master branch.
>
> 2) Apply your patch and check if applies successfully on the latest
> code.
>
> 3) Check for PEP8 issues
> - activate virtual env
> - cd ../web
> - yarn run pep8
>
> 4) Run regression test
> python regression/runtests.py
>
> - To run only UI/feature tests
> python regression/runtests.py --pkg feature_tests
>
> - To run regression test (without UI/Feature tests)
> python regression/runtests.py --exclude feature_tests
>
> 5) Run Jasmine tests
> - activate virtual env
> - cd ../web
> yarn run test:karma-once
>
> 6) Make sure to add or update help docs and screenshot(s) if you have
> added any new feature or changed any existing one.
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
> <===>
>
> But I am facing some issues,
> Step 1,2,3 and 5 had no issues
> But when I tried step 4 it gave some errors
> I executed the following command
>
> *python regression/runtests.py *
>
> I got the following errors:
> 1)The screenshot attached show I wasnt able to connect to the server
> 2) the error ouput on the command line:
> =Running the test cases for 'PostgreSQL 9.4'=
> Traceback (most recent call last):
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 128, in create_database
> server['sslmode']
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 36, in get_db_connection
> sslmode=sslmode
>   File 
> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
> line 130, in connect
> conn = _connect(dsn, connection_factory=connection_factory,
> **kwasync)
> OperationalError: FATAL:  password authentication failed for user
> "postgres"
> FATAL:  password authentication failed for user "postgres"
>
> Traceback (most recent call last):
>   File "regression/runtests.py", line 350, in 
> server_information = test_utils.create_parent_server_node(server)
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 491, in create_parent_server_node
> server_info['sslmode']
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 36, in get_db_connection
> sslmode=sslmode
>   File 
> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
> line 130, in connect
> conn = _connect(dsn, connection_factory=connection_factory,
> **kwasync)
> psycopg2.OperationalError: FATAL:  password authentication failed for
> user "postgres"
> FATAL:  password authentication failed for user "postgres"
>
> Traceback (most recent call last):
>   File 
> "/var/www/flask

Re: Little patch for Runtime build from Top Level Directory($PGADMIN_SRC) MakeFile

[Murtuza Zabuawala]

Have you configured your local test configuration file
../pgadmin4/web/regression/test_config.json.in , Make a copy of it as
../pgadmin4/web/regression/test_config.json and update it as per your
environment to run tests.

On Thu, Mar 22, 2018 at 4:18 PM, Rahul Soshte 
wrote:

> Although I have postgresql-9.6 it is showing-Running the test cases for
> 'PostgreSQL 9.4'
>
>
> On Thu, Mar 22, 2018 at 4:17 PM, Rahul Soshte 
> wrote:
>
>> Although I have postgresql-9.6 it is showing
>> --
>> --
>> Running the test cases for 'PostgreSQL 9.4'
>>
>> On Thu, Mar 22, 2018 at 4:01 PM, Rahul Soshte 
>> wrote:
>>
>>>
>>> -- Forwarded message --
>>> From: Rahul Soshte 
>>> Date: Thu, Mar 22, 2018 at 4:01 PM
>>> Subject: Re: Little patch for Runtime build from Top Level
>>> Directory($PGADMIN_SRC) MakeFile
>>> To: Murtuza Zabuawala 
>>>
>>>
>>> I am still getting the same error even when I did SERVER_MODE = False.
>>>
>>> On Thu, Mar 22, 2018 at 3:05 PM, Murtuza Zabuawala <
>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>
 You need to make SERVER_MODE = False in config_local.py in order to
 run feature tests.

 --
 Regards,
 Murtuza Zabuawala
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company


 On Thu, Mar 22, 2018 at 3:00 PM, Rahul Soshte >>> > wrote:

> how do I resolve those errors in step 4 of the checklist?
>
>
> On Thu, Mar 22, 2018 at 2:58 PM, Rahul Soshte <
> rahulsoshte...@gmail.com> wrote:
>
>> This is my first time trying to make a Patch.
>>
>> I am using Ubuntu 17.10.
>>
>> This patch is in reference to the Feature Added by Dave Page
>> https://redmine.postgresql.org/issues/1305
>>
>> I just added code to call makefile in runtime directory(
>> $PGADMIN_SRC/runtime/Makefile ) from the top level directory's MakeFile  
>> (
>> $PGADMIN_SRC/Makefile )
>>
>>
>> I followed the checklist for submitting a patch sent by Murutuza
>> Zabuawala
>>
>> <>
>> Hello,
>>
>> Here is the common checklist to follow before sending patch to
>> pgAdmin4-hackers group,
>>
>> 1) Get the latest pull from master branch.
>>
>> 2) Apply your patch and check if applies successfully on the latest
>> code.
>>
>> 3) Check for PEP8 issues
>> - activate virtual env
>> - cd ../web
>> - yarn run pep8
>>
>> 4) Run regression test
>> python regression/runtests.py
>>
>> - To run only UI/feature tests
>> python regression/runtests.py --pkg feature_tests
>>
>> - To run regression test (without UI/Feature tests)
>> python regression/runtests.py --exclude feature_tests
>>
>> 5) Run Jasmine tests
>> - activate virtual env
>> - cd ../web
>> yarn run test:karma-once
>>
>> 6) Make sure to add or update help docs and screenshot(s) if you have
>> added any new feature or changed any existing one.
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>> <===>
>>
>> But I am facing some issues,
>> Step 1,2,3 and 5 had no issues
>> But when I tried step 4 it gave some errors
>> I executed the following command
>>
>> *python regression/runtests.py *
>>
>> I got the following errors:
>> 1)The screenshot attached show I wasnt able to connect to the server
>> 2) the error ouput on the command line:
>> =Running the test cases for 'PostgreSQL 9.4'=
>> Traceback (most recent call last):
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 128, in create_database
>> server['sslmode']
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 36, in get_db_connection
>> sslmode=sslmode
>>   File 
>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>> line 130, in connect
>> conn = _connect(dsn, connection_factory=connection_factory,
>> **kwasync)
>> OperationalError: FATAL:  password authentication failed for user
>> "postgres"
>> FATAL:  password authentication failed for user "postgres"
>>
>> Traceback (most recent call last):
>>   File "regression/runtests.py", line 350, in 
>> server_information = test_utils.create_parent_server_node(server)
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 491, in create_parent_server_node
>> server_info['sslmode']
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 36, in get_db_connection
>> sslmode=sslmode
>>

pgAdmin 4 commit: Enable building of the runtime from the top level Mak

[Dave Page]

Enable building of the runtime from the top level Makefile. Fixes #1305

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=6d7f7952608b5bd07f20fa431ec540093f68d845
Author: Rahul Soshte 

Modified Files
--
Makefile | 13 +++--
docs/en_US/release_notes_3_0.rst |  1 +
2 files changed, 12 insertions(+), 2 deletions(-)

Re: Little patch for Runtime build from Top Level Directory($PGADMIN_SRC) MakeFile

[Dave Page]

Thanks - patch applied with a minor change of the target name
"runtime-release" to "runtime" (runtime-debug remains the same).

On Thu, Mar 22, 2018 at 9:28 AM, Rahul Soshte 
wrote:

> This is my first time trying to make a Patch.
>
> I am using Ubuntu 17.10.
>
> This patch is in reference to the Feature Added by Dave Page
> https://redmine.postgresql.org/issues/1305
>
> I just added code to call makefile in runtime directory(
> $PGADMIN_SRC/runtime/Makefile ) from the top level directory's MakeFile  (
> $PGADMIN_SRC/Makefile )
>
>
> I followed the checklist for submitting a patch sent by Murutuza Zabuawala
>
> <>
> Hello,
>
> Here is the common checklist to follow before sending patch to
> pgAdmin4-hackers group,
>
> 1) Get the latest pull from master branch.
>
> 2) Apply your patch and check if applies successfully on the latest code.
>
> 3) Check for PEP8 issues
> - activate virtual env
> - cd ../web
> - yarn run pep8
>
> 4) Run regression test
> python regression/runtests.py
>
> - To run only UI/feature tests
> python regression/runtests.py --pkg feature_tests
>
> - To run regression test (without UI/Feature tests)
> python regression/runtests.py --exclude feature_tests
>
> 5) Run Jasmine tests
> - activate virtual env
> - cd ../web
> yarn run test:karma-once
>
> 6) Make sure to add or update help docs and screenshot(s) if you have
> added any new feature or changed any existing one.
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
> <===>
>
> But I am facing some issues,
> Step 1,2,3 and 5 had no issues
> But when I tried step 4 it gave some errors
> I executed the following command
>
> *python regression/runtests.py *
>
> I got the following errors:
> 1)The screenshot attached show I wasnt able to connect to the server
> 2) the error ouput on the command line:
> =Running the test cases for 'PostgreSQL 9.4'=
> Traceback (most recent call last):
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 128, in create_database
> server['sslmode']
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 36, in get_db_connection
> sslmode=sslmode
>   File 
> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
> line 130, in connect
> conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
> OperationalError: FATAL:  password authentication failed for user
> "postgres"
> FATAL:  password authentication failed for user "postgres"
>
> Traceback (most recent call last):
>   File "regression/runtests.py", line 350, in 
> server_information = test_utils.create_parent_server_node(server)
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 491, in create_parent_server_node
> server_info['sslmode']
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 36, in get_db_connection
> sslmode=sslmode
>   File 
> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
> line 130, in connect
> conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
> psycopg2.OperationalError: FATAL:  password authentication failed for user
> "postgres"
> FATAL:  password authentication failed for user "postgres"
>
> Traceback (most recent call last):
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 619, in _cleanup
> connection = get_db_server(database["server_id"])
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 593, in get_db_server
> db_name, username, db_password, host, db_port, ssl_mode
>   File 
> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
> line 36, in get_db_connection
> sslmode=sslmode
>   File 
> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
> line 130, in connect
> conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
> OperationalError: FATAL:  password authentication failed for user
> "postgres"
> FATAL:  password authentication failed for user "postgres"
>
> I have no password authentication errors when I am connecting from the
> application.I had also changed password for postgres manually through the
> command line.
>



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

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

Re: v3.0 release on hold

[Akshay Joshi]

On Thu, Mar 22, 2018 at 3:22 PM, Dave Page  wrote:

> Hi
>
> On Thu, Mar 22, 2018 at 9:21 AM, Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Hi Dave
>>
>> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:
>>
>>> We've run into a number of unexpected issues with the v3.0 release that
>>> I think we need to resolve before moving forwards. For the time being, only
>>> patches critical to fix these issues should be committed.
>>>
>>> I'll try to look at 1, though I do have another deadline I need to meet.
>>> Akshay, can you look at 2 please?
>>> Fahar is already looking at 3.
>>> Khushboo, can you look at 4 please?
>>>
>>> Thanks all.
>>>
>>> 1) There is no longer a system tray in Gnome 3.26 and later, and thus
>>> the runtime won't initialise in Fedora 27 and later. We need an alternative
>>> for this, either a tray replacement that the RPM can depend on, or better
>>> yet, support whatever it is Gnome expect such apps to use these days.
>>>
>>> 2) Starting a second instance of the app bundle on Mac doesn't always
>>> open a new pgAdmin window as it should. It works fine in the debugger, or
>>> if you start the app with a command like: "/Applications/pgAdmin\
>>> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
>>> appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>>>
>>
>>   Still working on this, not found any solution yet.
>>
>
 Not able to figure out the solution yet. I have tried to debug the
code, but every time it will create a new instance(tray icon). Do I need to
look into the code or something related to app bundle may be some settings
in info.plist or any other pointer?

>
>>> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
>>> but apparently his is a fresh installation.
>>>
>>
>> I have tried on Windows 7 and Windows 8.1 64 bit clean VM (created
>> using ISO file) and pgAdmin4 is working fine on both. I have given the same
>> ISO file to Khushboo and she has created VM for both the OS and it is
>> crashed on her machine (seems strange behaviour), only difference is
>> version of VMWare fusion. I have 6.0.6 and she has 7.0.1
>>
>
> Is it possible that on one virtual machine VMware Tools were installed,
> but not on the other? I ask because I believe they install a version of the
> MSVC runtime.
>

On both machine VMware tools were installed.

>
>
>>
>>> 4) On my Windows 7 machine, after running a backup I get no status
>>> window, and see the following in the logs:
>>>
>>> Traceback (most recent call last):
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>>> line 209, in run_wsgi
>>> execute(self.server.app)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>>> line 197, in execute
>>> application_iter = app(environ, start_response)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1997, in __call__
>>> return self.wsgi_app(environ, start_response)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1985, in wsgi_app
>>> response = self.handle_exception(e)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1540, in handle_exception
>>> reraise(exc_type, exc_value, tb)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1982, in wsgi_app
>>> response = self.full_dispatch_request()
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1614, in full_dispatch_request
>>> rv = self.handle_user_exception(e)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1517, in handle_user_exception
>>> reraise(exc_type, exc_value, tb)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1612, in full_dispatch_request
>>> rv = self.dispatch_request()
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask\app.py",
>>> line 1598, in dispatch_request
>>> return self.view_functions[rule.endpoint](**req.view_args)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\venv\Lib\site-packages\flask_login.py",
>>> line 792, in decorated_view
>>> return func(*args, **kwargs)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\web\pgadmin\misc\bgprocess\__init__.py",
>>> line 62, in index
>>> return make_response(response=BatchProcess.list())
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\web\pgadmin\misc\bgprocess\processes.py",
>>> line 584, in list
>>> details = desc.details(p.command, args)
>>>   File "C:\Program Files (x86)\pgAdmin 
>>> 4\v3\web\pgadmin\tools\backup\__init__.py",
>>> line 190, in details
>>> res += html.safe_str(cmd + self.cmd)
>>> AttributeError: 'BackupMessage' object has no attribute 'cmd'
>>>

Re: v3.0 release on hold

[Dave Page]

Hi

On Thu, Mar 22, 2018 at 1:00 PM, Akshay Joshi  wrote:

>
>
> On Thu, Mar 22, 2018 at 3:22 PM, Dave Page  wrote:
>
>> Hi
>>
>> On Thu, Mar 22, 2018 at 9:21 AM, Akshay Joshi <
>> akshay.jo...@enterprisedb.com> wrote:
>>
>>> Hi Dave
>>>
>>> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:
>>>
 We've run into a number of unexpected issues with the v3.0 release that
 I think we need to resolve before moving forwards. For the time being, only
 patches critical to fix these issues should be committed.

 I'll try to look at 1, though I do have another deadline I need to
 meet.
 Akshay, can you look at 2 please?
 Fahar is already looking at 3.
 Khushboo, can you look at 4 please?

 Thanks all.

 1) There is no longer a system tray in Gnome 3.26 and later, and thus
 the runtime won't initialise in Fedora 27 and later. We need an alternative
 for this, either a tray replacement that the RPM can depend on, or better
 yet, support whatever it is Gnome expect such apps to use these days.

 2) Starting a second instance of the app bundle on Mac doesn't always
 open a new pgAdmin window as it should. It works fine in the debugger, or
 if you start the app with a command like: "/Applications/pgAdmin\
 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click
 the appbundle or use a command like "open /Applications/pgAdmin\ 4.app"

>>>
>>>   Still working on this, not found any solution yet.
>>>
>>
>  Not able to figure out the solution yet. I have tried to debug
> the code, but every time it will create a new instance(tray icon). Do I
> need to look into the code or something related to app bundle may be some
> settings in info.plist or any other pointer?
>

Have a look at the code around line 85 an onwards of pgAdmin4.cpp. It
creates the shared memory interlock (and log/address files) based on the
current username and a hash of the executable name/path. My suspicion is
that the path hash (which is calculated from argv[0] on line 72) is for
some reason getting a different value each time when launched via the
Finder or "open", thus the interlock is failing.



>
 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my
 copy, but apparently his is a fresh installation.

>>>
>>> I have tried on Windows 7 and Windows 8.1 64 bit clean VM (created
>>> using ISO file) and pgAdmin4 is working fine on both. I have given the same
>>> ISO file to Khushboo and she has created VM for both the OS and it is
>>> crashed on her machine (seems strange behaviour), only difference is
>>> version of VMWare fusion. I have 6.0.6 and she has 7.0.1
>>>
>>
>> Is it possible that on one virtual machine VMware Tools were installed,
>> but not on the other? I ask because I believe they install a version of the
>> MSVC runtime.
>>
>
> On both machine VMware tools were installed.
>

Odd. Very odd.


>
>>
>>>
 4) On my Windows 7 machine, after running a backup I get no status
 window, and see the following in the logs:

 Traceback (most recent call last):
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
 line 209, in run_wsgi
 execute(self.server.app)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
 line 197, in execute
 application_iter = app(environ, start_response)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1997, in __call__
 return self.wsgi_app(environ, start_response)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1985, in wsgi_app
 response = self.handle_exception(e)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1540, in handle_exception
 reraise(exc_type, exc_value, tb)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1982, in wsgi_app
 response = self.full_dispatch_request()
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1614, in full_dispatch_request
 rv = self.handle_user_exception(e)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1517, in handle_user_exception
 reraise(exc_type, exc_value, tb)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1612, in full_dispatch_request
 rv = self.dispatch_request()
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask\app.py",
 line 1598, in dispatch_request
 return self.view_functions[rule.endpoint](**req.view_args)
   File "C:\Program Files (x86)\pgAdmin 
 4\v3\venv\Lib\site-packages\flask_login.py",
 line 792, in decorated_v

Re: Little patch for Runtime build from Top Level Directory($PGADMIN_SRC) MakeFile

[Rahul Soshte]

there is a small typo in the target name "all" runtime-release needs to be
changed runtime too.

On Thu, Mar 22, 2018 at 4:50 PM, Dave Page  wrote:

> Thanks - patch applied with a minor change of the target name
> "runtime-release" to "runtime" (runtime-debug remains the same).
>
> On Thu, Mar 22, 2018 at 9:28 AM, Rahul Soshte 
> wrote:
>
>> This is my first time trying to make a Patch.
>>
>> I am using Ubuntu 17.10.
>>
>> This patch is in reference to the Feature Added by Dave Page
>> https://redmine.postgresql.org/issues/1305
>>
>> I just added code to call makefile in runtime directory(
>> $PGADMIN_SRC/runtime/Makefile ) from the top level directory's MakeFile  (
>> $PGADMIN_SRC/Makefile )
>>
>>
>> I followed the checklist for submitting a patch sent by Murutuza Zabuawala
>>
>> <>
>> Hello,
>>
>> Here is the common checklist to follow before sending patch to
>> pgAdmin4-hackers group,
>>
>> 1) Get the latest pull from master branch.
>>
>> 2) Apply your patch and check if applies successfully on the latest code.
>>
>> 3) Check for PEP8 issues
>> - activate virtual env
>> - cd ../web
>> - yarn run pep8
>>
>> 4) Run regression test
>> python regression/runtests.py
>>
>> - To run only UI/feature tests
>> python regression/runtests.py --pkg feature_tests
>>
>> - To run regression test (without UI/Feature tests)
>> python regression/runtests.py --exclude feature_tests
>>
>> 5) Run Jasmine tests
>> - activate virtual env
>> - cd ../web
>> yarn run test:karma-once
>>
>> 6) Make sure to add or update help docs and screenshot(s) if you have
>> added any new feature or changed any existing one.
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>> <===>
>>
>> But I am facing some issues,
>> Step 1,2,3 and 5 had no issues
>> But when I tried step 4 it gave some errors
>> I executed the following command
>>
>> *python regression/runtests.py *
>>
>> I got the following errors:
>> 1)The screenshot attached show I wasnt able to connect to the server
>> 2) the error ouput on the command line:
>> =Running the test cases for 'PostgreSQL 9.4'=
>> Traceback (most recent call last):
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 128, in create_database
>> server['sslmode']
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 36, in get_db_connection
>> sslmode=sslmode
>>   File 
>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>> line 130, in connect
>> conn = _connect(dsn, connection_factory=connection_factory,
>> **kwasync)
>> OperationalError: FATAL:  password authentication failed for user
>> "postgres"
>> FATAL:  password authentication failed for user "postgres"
>>
>> Traceback (most recent call last):
>>   File "regression/runtests.py", line 350, in 
>> server_information = test_utils.create_parent_server_node(server)
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 491, in create_parent_server_node
>> server_info['sslmode']
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 36, in get_db_connection
>> sslmode=sslmode
>>   File 
>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>> line 130, in connect
>> conn = _connect(dsn, connection_factory=connection_factory,
>> **kwasync)
>> psycopg2.OperationalError: FATAL:  password authentication failed for
>> user "postgres"
>> FATAL:  password authentication failed for user "postgres"
>>
>> Traceback (most recent call last):
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 619, in _cleanup
>> connection = get_db_server(database["server_id"])
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 593, in get_db_server
>> db_name, username, db_password, host, db_port, ssl_mode
>>   File 
>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>> line 36, in get_db_connection
>> sslmode=sslmode
>>   File 
>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>> line 130, in connect
>> conn = _connect(dsn, connection_factory=connection_factory,
>> **kwasync)
>> OperationalError: FATAL:  password authentication failed for user
>> "postgres"
>> FATAL:  password authentication failed for user "postgres"
>>
>> I have no password authentication errors when I am connecting from the
>> application.I had also changed password for postgres manually through the
>> command line.
>>
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterpris

pgAdmin 4 commit: Fix target dependency per Rahul Soshte.

[Dave Page]

Fix target dependency per Rahul Soshte.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=d5ebf6777a5470e4c39a5348bcf375534bd5e9c4

Modified Files
--
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Re: Little patch for Runtime build from Top Level Directory($PGADMIN_SRC) MakeFile

[Dave Page]

Rats, my bad. Fixed now - thanks.

On Thu, Mar 22, 2018 at 1:41 PM, Rahul Soshte 
wrote:

> there is a small typo in the target name "all" runtime-release needs to be
> changed runtime too.
>
> On Thu, Mar 22, 2018 at 4:50 PM, Dave Page  wrote:
>
>> Thanks - patch applied with a minor change of the target name
>> "runtime-release" to "runtime" (runtime-debug remains the same).
>>
>> On Thu, Mar 22, 2018 at 9:28 AM, Rahul Soshte 
>> wrote:
>>
>>> This is my first time trying to make a Patch.
>>>
>>> I am using Ubuntu 17.10.
>>>
>>> This patch is in reference to the Feature Added by Dave Page
>>> https://redmine.postgresql.org/issues/1305
>>>
>>> I just added code to call makefile in runtime directory(
>>> $PGADMIN_SRC/runtime/Makefile ) from the top level directory's MakeFile  (
>>> $PGADMIN_SRC/Makefile )
>>>
>>>
>>> I followed the checklist for submitting a patch sent by Murutuza
>>> Zabuawala
>>>
>>> <>
>>> Hello,
>>>
>>> Here is the common checklist to follow before sending patch to
>>> pgAdmin4-hackers group,
>>>
>>> 1) Get the latest pull from master branch.
>>>
>>> 2) Apply your patch and check if applies successfully on the latest code.
>>>
>>> 3) Check for PEP8 issues
>>> - activate virtual env
>>> - cd ../web
>>> - yarn run pep8
>>>
>>> 4) Run regression test
>>> python regression/runtests.py
>>>
>>> - To run only UI/feature tests
>>> python regression/runtests.py --pkg feature_tests
>>>
>>> - To run regression test (without UI/Feature tests)
>>> python regression/runtests.py --exclude feature_tests
>>>
>>> 5) Run Jasmine tests
>>> - activate virtual env
>>> - cd ../web
>>> yarn run test:karma-once
>>>
>>> 6) Make sure to add or update help docs and screenshot(s) if you have
>>> added any new feature or changed any existing one.
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>> <===>
>>>
>>> But I am facing some issues,
>>> Step 1,2,3 and 5 had no issues
>>> But when I tried step 4 it gave some errors
>>> I executed the following command
>>>
>>> *python regression/runtests.py *
>>>
>>> I got the following errors:
>>> 1)The screenshot attached show I wasnt able to connect to the server
>>> 2) the error ouput on the command line:
>>> =Running the test cases for 'PostgreSQL 9.4'=
>>> Traceback (most recent call last):
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 128, in create_database
>>> server['sslmode']
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 36, in get_db_connection
>>> sslmode=sslmode
>>>   File 
>>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>>> line 130, in connect
>>> conn = _connect(dsn, connection_factory=connection_factory,
>>> **kwasync)
>>> OperationalError: FATAL:  password authentication failed for user
>>> "postgres"
>>> FATAL:  password authentication failed for user "postgres"
>>>
>>> Traceback (most recent call last):
>>>   File "regression/runtests.py", line 350, in 
>>> server_information = test_utils.create_parent_server_node(server)
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 491, in create_parent_server_node
>>> server_info['sslmode']
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 36, in get_db_connection
>>> sslmode=sslmode
>>>   File 
>>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>>> line 130, in connect
>>> conn = _connect(dsn, connection_factory=connection_factory,
>>> **kwasync)
>>> psycopg2.OperationalError: FATAL:  password authentication failed for
>>> user "postgres"
>>> FATAL:  password authentication failed for user "postgres"
>>>
>>> Traceback (most recent call last):
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 619, in _cleanup
>>> connection = get_db_server(database["server_id"])
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 593, in get_db_server
>>> db_name, username, db_password, host, db_port, ssl_mode
>>>   File 
>>> "/var/www/flask/pgadmin4/pgadmin4/web/regression/python_test_utils/test_utils.py",
>>> line 36, in get_db_connection
>>> sslmode=sslmode
>>>   File 
>>> "/var/www/flask/pgadmin4/local/lib/python2.7/site-packages/psycopg2/__init__.py",
>>> line 130, in connect
>>> conn = _connect(dsn, connection_factory=connection_factory,
>>> **kwasync)
>>> OperationalError: FATAL:  password authentication failed for user
>>> "postgres"
>>> FATAL:  password authentication failed for user "postgres"
>>>
>>> I have no password authentication errors when I am connecting from the
>>> app

Re: Showstopper desktop runtime issue

[Joao De Almeida Pereira]

Hello Hackers,
Here is our take on the 3 options present:
1) QtWebkit and QtWebEngine

Pros:
- Webkit is a mature technology that as been around for some time
- Apparently the Fork of Webkit we were using as been catching up
Cons:
- We are using a Fork
- It is to far behind of the today browsers and the competition keep
evolving making it even harder for them to catch up
- Problems with the environment from the past, lagginess, lack of support

2) Rework runtime to find a running PGAdmin and attach to it

Pros:
- We already made the big move from Webkit to this version
- Add smarts to the application to do not run itself if it is already
running, or kill the currently running application

Cons:
- More C++ code thrown around
- Add more dependency on our QT application
- Have specific code for Gnome, not even a OS version but a window manager

3) Electron

Pros:
- Full Javascript runtime, no more C++ code to handle
- Self packaging for all the environments
Cons:
- No fully supported on Linux based OS with old libstdc++, (This might
solve the problem: https://github.com/mattermost/desktop/issues/312)
- CPU/RAM high utilization (Found a issues around and the majority of them
have solutions like CSS animations running or settings on the created
windows)
- Electron does not support tabs by default, only HTML tabs

After combing through these options with some pros and cons  here are my
thoughts:
1) This options was always cluncky from the beginning, the fact that we are
working with a browser that is currently 26k commits behind Webkit:master
is concerning. So I do not believe this is a viable option. As a personal
opinion is we need to release fast, then we should go with what we have now
and not go back to this option.
2) This option is not very appealing to me, because we would be pilling
code into the QT portion of the application, that I hope we remove in the
future, that currently is untested to solve a problem caused by a Window
Manager..
I would be more in favor of creating a Application Indicator that would
support 2 actions, Kill running pgAdmins and launch the browser to access
them. There is a lot of interesting websites that talk about this, and how
to develop. I had to download one to have a docker indicator. But as I
said in a previous thread, I believe that this should be a 3rd party
application and not a first class citizen on pgAdmin, as the majority of
the ones that I found are.
3) Electron can to play, first when we though about removing QTWebkit,
because it always packs a browser with it and also and there is a very big
Open Source Community being it. It came back again when when we saw that we
were ready to ditch the browser. (As a personal note I dislike applications
that I install in my machine and pop browser open to do anything, this is a
personal issue that I would like to see if it was shared by others that was
why we decided to park Electron for a second time. Because if our users are
ok with it there is no need to add extra complexity to the product)
The most interesting thing about the cons that I found in Electron there is
an issue open for them and a bunch of different solutions to try to handle
it, or even advises on how to handle it. This option also allow us to focus
less on browser compatibility as the main target of our development will
become Chromium which is the base of browsers like UC Browser, Vivaldi,
Opera, Google Chrome.

As you could see from my long long email, I am biased towards options 3,
not because I started the push for it, but because I believe it is the
right step for this product. This being said, I think that releasing now
with this current issue is Ok as a first step to somewhere.

Thanks
Joao

On Thu, Mar 22, 2018 at 6:48 AM Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> On Thu, Mar 22, 2018 at 3:19 PM, Dave Page  wrote:
>
>> All,
>>
>> As you know, the 3.0 release is currently on hold as we discovered late
>> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
>> later. This is because the GTK project, and later Gnome, have removed
>> support for the System Tray on which the new runtime relies.
>>
>> They have replaced it with a notification mechanism, however this doesn't
>> really meet our needs as what we want is a place (the tray icon) to attach
>> a menu to control the pgAdmin server; we don't really use notifications as
>> such.
>>
>> I see a number of possible ways around this:
>>
>> 1) Return to the previous runtime. I think this is at best a short-term
>> solution, as the re-visited Annulen version of the QtWebKit seems to be
>> getting little attention at the moment, and this would re-introduce many
>> known bugs caused by WebKit.
>>
> ​I would not prefer going back after seeing QtWebkit & QtWebEngine issues
> in the past.​
>
>
>>
>> 2) Re-work the current runtime code to remove the tray icon, and utilise
>> desktop/start menu items to signal the running instance to show the logs,
>> configur

Re: Showstopper desktop runtime issue

[Dave Page]

Hi

On Thu, Mar 22, 2018 at 2:57 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Hackers,
> Here is our take on the 3 options present:
> 1) QtWebkit and QtWebEngine
>
> Pros:
> - Webkit is a mature technology that as been around for some time
> - Apparently the Fork of Webkit we were using as been catching up
> Cons:
> - We are using a Fork
> - It is to far behind of the today browsers and the competition keep
> evolving making it even harder for them to catch up
> - Problems with the environment from the past, lagginess, lack of support
>
> 2) Rework runtime to find a running PGAdmin and attach to it
>
> Pros:
> - We already made the big move from Webkit to this version
> - Add smarts to the application to do not run itself if it is already
> running, or kill the currently running application
>
> Cons:
> - More C++ code thrown around
> - Add more dependency on our QT application
> - Have specific code for Gnome, not even a OS version but a window manager
>
> 3) Electron
>
> Pros:
> - Full Javascript runtime, no more C++ code to handle
> - Self packaging for all the environments
> Cons:
> - No fully supported on Linux based OS with old libstdc++, (This might
> solve the problem: https://github.com/mattermost/desktop/issues/312)
> - CPU/RAM high utilization (Found a issues around and the majority of them
> have solutions like CSS animations running or settings on the created
> windows)
> - Electron does not support tabs by default, only HTML tabs
>
> After combing through these options with some pros and cons  here are my
> thoughts:
> 1) This options was always cluncky from the beginning, the fact that we
> are working with a browser that is currently 26k commits behind
> Webkit:master is concerning. So I do not believe this is a viable option.
> As a personal opinion is we need to release fast, then we should go with
> what we have now and not go back to this option.
> 2) This option is not very appealing to me, because we would be pilling
> code into the QT portion of the application, that I hope we remove in the
> future, that currently is untested to solve a problem caused by a Window
> Manager..
> I would be more in favor of creating a Application Indicator that would
> support 2 actions, Kill running pgAdmins and launch the browser to access
> them. There is a lot of interesting websites that talk about this, and how
> to develop. I had to download one to have a docker indicator. But as I
> said in a previous thread, I believe that this should be a 3rd party
> application and not a first class citizen on pgAdmin, as the majority of
> the ones that I found are.
> 3) Electron can to play, first when we though about removing QTWebkit,
> because it always packs a browser with it and also and there is a very big
> Open Source Community being it. It came back again when when we saw that we
> were ready to ditch the browser. (As a personal note I dislike applications
> that I install in my machine and pop browser open to do anything, this is a
> personal issue that I would like to see if it was shared by others that was
> why we decided to park Electron for a second time. Because if our users are
> ok with it there is no need to add extra complexity to the product)
> The most interesting thing about the cons that I found in Electron there
> is an issue open for them and a bunch of different solutions to try to
> handle it, or even advises on how to handle it. This option also allow us
> to focus less on browser compatibility as the main target of our
> development will become Chromium which is the base of browsers like UC
> Browser, Vivaldi, Opera, Google Chrome.
>
> As you could see from my long long email, I am biased towards options 3,
> not because I started the push for it, but because I believe it is the
> right step for this product. This being said, I think that releasing now
> with this current issue is Ok as a first step to somewhere.
>

I think in the longer term, 3 is probably the best option. Whilst the
current architecture (where it works) is a good improvement and gets rid of
the QtWebKit/QtWebEngine problems, I'm not a huge fan of having a server
and browser; I much prefer the idea of having a single app.

How much effort do you think it would be to get the Electron based browser
to a usable state, in which everything is nicely packaged and buildable,
but without the tab support?

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

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

Re: Showstopper desktop runtime issue

[Magnus Hagander]

On Thu, Mar 22, 2018 at 3:57 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Hackers,
> Here is our take on the 3 options present:
>

This looks like a good summary, so I'm going to pick this one to comment on
:)




> 1) QtWebkit and QtWebEngine
>

> Pros:
> - Webkit is a mature technology that as been around for some time
> - Apparently the Fork of Webkit we were using as been catching up
> Cons:
> - We are using a Fork
> - It is to far behind of the today browsers and the competition keep
> evolving making it even harder for them to catch up
> - Problems with the environment from the past, lagginess, lack of support
>
>
Yeah, this one hasn't exactly caused a "little" set of complaints so far.
It might be workable for absolute stop-gap, but not beyond that.



> 2) Rework runtime to find a running PGAdmin and attach to it
>
> Pros:
> - We already made the big move from Webkit to this version
> - Add smarts to the application to do not run itself if it is already
> running, or kill the currently running application
>
> Cons:
> - More C++ code thrown around
> - Add more dependency on our QT application
> - Have specific code for Gnome, not even a OS version but a window manager
>


Annoying as it is, I think this is the least bad option at this point.


3) Electron
>
> Pros:
> - Full Javascript runtime, no more C++ code to handle
> - Self packaging for all the environments
> Cons:
> - No fully supported on Linux based OS with old libstdc++, (This might
> solve the problem: https://github.com/mattermost/desktop/issues/312)
>


Losing support for things like RHEL6 would make it completely unworkable
for several of my largest customers. Particularly in large enterprise
organisations, this would be a very substantial issue.



> - CPU/RAM high utilization (Found a issues around and the majority of them
> have solutions like CSS animations running or settings on the created
> windows)
>

This does sound bad. But do we actually know if this is worse in Electron
than it is in the option #2? I mean sure, we point to things like Slack,
but that may not be because of electron, it may be because the app running
inside it?



> - Electron does not support tabs by default, only HTML tabs
>

I think that also makes it a showstopper. This was another one of the main
complaints I have personally heard from people going from pgadmin3 ->
pgadmin4, and enough to make people not want to use it at all. It would be
really bad to go back to that.



After combing through these options with some pros and cons  here are my
> thoughts:
> 1) This options was always cluncky from the beginning, the fact that we
> are working with a browser that is currently 26k commits behind
> Webkit:master is concerning. So I do not believe this is a viable option.
> As a personal opinion is we need to release fast, then we should go with
> what we have now and not go back to this option.
>

Yeah, that option definitely has no future long-term.



> 2) This option is not very appealing to me, because we would be pilling
> code into the QT portion of the application, that I hope we remove in the
> future, that currently is untested to solve a problem caused by a Window
> Manager..
> I would be more in favor of creating a Application Indicator that would
> support 2 actions, Kill running pgAdmins and launch the browser to access
> them. There is a lot of interesting websites that talk about this, and how
> to develop. I had to download one to have a docker indicator. But as I
> said in a previous thread, I believe that this should be a 3rd party
> application and not a first class citizen on pgAdmin, as the majority of
> the ones that I found are.
>

I can't comment on the specific ways to sort it out, but I think *basing*
things in option 2 is by far the best option. If it's just an additional
add-on that can be made a dependency of the packages it's not a huge
problem (provided this add-on is available on the major platforms like
rhel, ubuntu, debian of course)




> 3) Electron can to play, first when we though about removing QTWebkit,
> because it always packs a browser with it and also and there is a very big
> Open Source Community being it. It came back again when when we saw that we
> were ready to ditch the browser. (As a personal note I dislike applications
> that I install in my machine and pop browser open to do anything, this is a
> personal issue that I would like to see if it was shared by others that was
> why we decided to park Electron for a second time. Because if our users are
> ok with it there is no need to add extra complexity to the product)
> The most interesting thing about the cons that I found in Electron there
> is an issue open for them and a bunch of different solutions to try to
> handle it, or even advises on how to handle it. This option also allow us
> to focus less on browser compatibility as the main target of our
> development will become Chromium which is the base of browsers l

Re: Showstopper desktop runtime issue

[Dave Page]

Hi

On Thu, Mar 22, 2018 at 4:17 PM, Magnus Hagander 
wrote:

>
>
> On Thu, Mar 22, 2018 at 3:57 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hello Hackers,
>> Here is our take on the 3 options present:
>>
>
> This looks like a good summary, so I'm going to pick this one to comment
> on :)
>

:-)


>
>
>
>
>> 1) QtWebkit and QtWebEngine
>>
>
>> Pros:
>> - Webkit is a mature technology that as been around for some time
>> - Apparently the Fork of Webkit we were using as been catching up
>> Cons:
>> - We are using a Fork
>> - It is to far behind of the today browsers and the competition keep
>> evolving making it even harder for them to catch up
>> - Problems with the environment from the past, lagginess, lack of support
>>
>>
> Yeah, this one hasn't exactly caused a "little" set of complaints so far.
> It might be workable for absolute stop-gap, but not beyond that.
>

Right.


>
>
>
>> 2) Rework runtime to find a running PGAdmin and attach to it
>>
>> Pros:
>> - We already made the big move from Webkit to this version
>> - Add smarts to the application to do not run itself if it is already
>> running, or kill the currently running application
>>
>> Cons:
>> - More C++ code thrown around
>> - Add more dependency on our QT application
>> - Have specific code for Gnome, not even a OS version but a window manager
>>
>
>
> Annoying as it is, I think this is the least bad option at this point.
>
>
> 3) Electron
>>
>> Pros:
>> - Full Javascript runtime, no more C++ code to handle
>> - Self packaging for all the environments
>> Cons:
>> - No fully supported on Linux based OS with old libstdc++, (This might
>> solve the problem: https://github.com/mattermost/desktop/issues/312)
>>
>
>
> Losing support for things like RHEL6 would make it completely unworkable
> for several of my largest customers. Particularly in large enterprise
> organisations, this would be a very substantial issue.
>

That's good to know. There are clunky workarounds (shipping different libcs
for example, but that potentially adds licensing issues).

Sidenote: It would only be an issue for desktop mode. Web mode should not
be affected.


>
>
>
>> - CPU/RAM high utilization (Found a issues around and the majority of
>> them have solutions like CSS animations running or settings on the created
>> windows)
>>
>
> This does sound bad. But do we actually know if this is worse in Electron
> than it is in the option #2? I mean sure, we point to things like Slack,
> but that may not be because of electron, it may be because the app running
> inside it?
>

We don't know for sure, but we do know that Chrome in general is a bit of a
hog. It's certainly not a stretch to think a combination of those things
are why people (correctly) see browser based apps as being more resource
hungry.


>
>
>
>> - Electron does not support tabs by default, only HTML tabs
>>
>
> I think that also makes it a showstopper. This was another one of the main
> complaints I have personally heard from people going from pgadmin3 ->
> pgadmin4, and enough to make people not want to use it at all. It would be
> really bad to go back to that.
>

To clarify; it would mean no tabs, but not single window. That was already
working in the PoC. In other words, helpfiles, the debugger and query tools
could all be opened in new windows, just not tabs on the same window that
could be docked and un-docked.

I suspect for most people that would be enough.


>
>
>
> After combing through these options with some pros and cons  here are my
>> thoughts:
>> 1) This options was always cluncky from the beginning, the fact that we
>> are working with a browser that is currently 26k commits behind
>> Webkit:master is concerning. So I do not believe this is a viable option.
>> As a personal opinion is we need to release fast, then we should go with
>> what we have now and not go back to this option.
>>
>
> Yeah, that option definitely has no future long-term.
>
>
>
>> 2) This option is not very appealing to me, because we would be pilling
>> code into the QT portion of the application, that I hope we remove in the
>> future, that currently is untested to solve a problem caused by a Window
>> Manager..
>> I would be more in favor of creating a Application Indicator that would
>> support 2 actions, Kill running pgAdmins and launch the browser to access
>> them. There is a lot of interesting websites that talk about this, and how
>> to develop. I had to download one to have a docker indicator. But as I
>> said in a previous thread, I believe that this should be a 3rd party
>> application and not a first class citizen on pgAdmin, as the majority of
>> the ones that I found are.
>>
>
> I can't comment on the specific ways to sort it out, but I think *basing*
> things in option 2 is by far the best option. If it's just an additional
> add-on that can be made a dependency of the packages it's not a huge
> problem (provided this add-on is available on the major platforms like
> 

Re: Showstopper desktop runtime issue

[Robert Eckhardt]

On Thu, Mar 22, 2018 at 12:28 PM, Dave Page  wrote:

> Hi
>
> On Thu, Mar 22, 2018 at 4:17 PM, Magnus Hagander 
> wrote:
>
>>
>>
>> On Thu, Mar 22, 2018 at 3:57 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Hello Hackers,
>>> Here is our take on the 3 options present:
>>>
>>
>> This looks like a good summary, so I'm going to pick this one to comment
>> on :)
>>
>
> :-)
>
>
>>
>>
>>
>>
>>> 1) QtWebkit and QtWebEngine
>>>
>>
>>> Pros:
>>> - Webkit is a mature technology that as been around for some time
>>> - Apparently the Fork of Webkit we were using as been catching up
>>> Cons:
>>> - We are using a Fork
>>> - It is to far behind of the today browsers and the competition keep
>>> evolving making it even harder for them to catch up
>>> - Problems with the environment from the past, lagginess, lack of support
>>>
>>>
>> Yeah, this one hasn't exactly caused a "little" set of complaints so far.
>> It might be workable for absolute stop-gap, but not beyond that.
>>
>
> Right.
>
>
>>
>>
>>
>>> 2) Rework runtime to find a running PGAdmin and attach to it
>>>
>>> Pros:
>>> - We already made the big move from Webkit to this version
>>> - Add smarts to the application to do not run itself if it is already
>>> running, or kill the currently running application
>>>
>>> Cons:
>>> - More C++ code thrown around
>>> - Add more dependency on our QT application
>>> - Have specific code for Gnome, not even a OS version but a window
>>> manager
>>>
>>
>>
>> Annoying as it is, I think this is the least bad option at this point.
>>
>>
>> 3) Electron
>>>
>>> Pros:
>>> - Full Javascript runtime, no more C++ code to handle
>>> - Self packaging for all the environments
>>> Cons:
>>> - No fully supported on Linux based OS with old libstdc++, (This might
>>> solve the problem: https://github.com/mattermost/desktop/issues/312)
>>>
>>
>>
>> Losing support for things like RHEL6 would make it completely unworkable
>> for several of my largest customers. Particularly in large enterprise
>> organisations, this would be a very substantial issue.
>>
>
> That's good to know. There are clunky workarounds (shipping different
> libcs for example, but that potentially adds licensing issues).
>
> Sidenote: It would only be an issue for desktop mode. Web mode should not
> be affected.
>
>
>>
>>
>>
>>> - CPU/RAM high utilization (Found a issues around and the majority of
>>> them have solutions like CSS animations running or settings on the created
>>> windows)
>>>
>>
>> This does sound bad. But do we actually know if this is worse in Electron
>> than it is in the option #2? I mean sure, we point to things like Slack,
>> but that may not be because of electron, it may be because the app running
>> inside it?
>>
>
> We don't know for sure, but we do know that Chrome in general is a bit of
> a hog. It's certainly not a stretch to think a combination of those things
> are why people (correctly) see browser based apps as being more resource
> hungry.
>

I honestly think this is a fair criticism. I like electron and wish it
weren't.


>
>
>>
>>
>>
>>> - Electron does not support tabs by default, only HTML tabs
>>>
>>
>> I think that also makes it a showstopper. This was another one of the
>> main complaints I have personally heard from people going from pgadmin3 ->
>> pgadmin4, and enough to make people not want to use it at all. It would be
>> really bad to go back to that.
>>
>
> To clarify; it would mean no tabs, but not single window. That was already
> working in the PoC. In other words, helpfiles, the debugger and query tools
> could all be opened in new windows, just not tabs on the same window that
> could be docked and un-docked.
>
> I suspect for most people that would be enough.
>

Agreed, I also think that adding tabs is a doable feature it just isn't an
'out of the box' thing.


>
>
>>
>>
>>
>> After combing through these options with some pros and cons  here are my
>>> thoughts:
>>> 1) This options was always cluncky from the beginning, the fact that we
>>> are working with a browser that is currently 26k commits behind
>>> Webkit:master is concerning. So I do not believe this is a viable option.
>>> As a personal opinion is we need to release fast, then we should go with
>>> what we have now and not go back to this option.
>>>
>>
>> Yeah, that option definitely has no future long-term.
>>
>>
>>
>>> 2) This option is not very appealing to me, because we would be pilling
>>> code into the QT portion of the application, that I hope we remove in the
>>> future, that currently is untested to solve a problem caused by a Window
>>> Manager..
>>> I would be more in favor of creating a Application Indicator that would
>>> support 2 actions, Kill running pgAdmins and launch the browser to access
>>> them. There is a lot of interesting websites that talk about this, and how
>>> to develop. I had to download one to have a docker indicator. But as I
>>> said in a previous thread, I believe that this should be a 3

Re: v3.0 release on hold

[Dave Page]

Hi

On Thu, Mar 22, 2018 at 1:13 PM, Dave Page  wrote:

>
> 2) Starting a second instance of the app bundle on Mac doesn't always
> open a new pgAdmin window as it should. It works fine in the debugger, or
> if you start the app with a command like: "/Applications/pgAdmin\
> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click
> the appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>

   Still working on this, not found any solution yet.

>>>
>>  Not able to figure out the solution yet. I have tried to debug
>> the code, but every time it will create a new instance(tray icon). Do I
>> need to look into the code or something related to app bundle may be some
>> settings in info.plist or any other pointer?
>>
>
> Have a look at the code around line 85 an onwards of pgAdmin4.cpp. It
> creates the shared memory interlock (and log/address files) based on the
> current username and a hash of the executable name/path. My suspicion is
> that the path hash (which is calculated from argv[0] on line 72) is for
> some reason getting a different value each time when launched via the
> Finder or "open", thus the interlock is failing.
>

So I took a look at this, and it seems the code is just fine. What is
happening is that macOS only allows a single instance of an app to run at
once. Whilst that is what we want of course, macOS is causing the new
instance to exit before it has a change to open a new pgAdmin window. Using
"open -n ..." or calling the embedded executable directly resolves that
issue.

So, there's another challenge to figure out... :-(

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

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

Re: Showstopper desktop runtime issue

[Dave Page]

On Thu, Mar 22, 2018 at 4:28 PM, Dave Page  wrote:

>
> 2) This option is not very appealing to me, because we would be pilling
>>> code into the QT portion of the application, that I hope we remove in the
>>> future, that currently is untested to solve a problem caused by a Window
>>> Manager..
>>> I would be more in favor of creating a Application Indicator that would
>>> support 2 actions, Kill running pgAdmins and launch the browser to access
>>> them. There is a lot of interesting websites that talk about this, and how
>>> to develop. I had to download one to have a docker indicator. But as I
>>> said in a previous thread, I believe that this should be a 3rd party
>>> application and not a first class citizen on pgAdmin, as the majority of
>>> the ones that I found are.
>>>
>>
>> I can't comment on the specific ways to sort it out, but I think *basing*
>> things in option 2 is by far the best option. If it's just an additional
>> add-on that can be made a dependency of the packages it's not a huge
>> problem (provided this add-on is available on the major platforms like
>> rhel, ubuntu, debian of course)
>>
>
> It would just be a modified version of what we have. Instead of having an
> icon in the system tray, we'd probably have multiple Start Menu icons to
> replace the tray icon menu. They would have to signal a running instance to
> do something, or become a new instance and then do the something if nothing
> is running already.
>

Of course, another option here might be to figure out that we're running
under Gnome/GTK at runtime, and if so, create an indicator icon and menu
instead of the tray icon. That is, apparently, what Skype and other similar
apps do now. The indicator icons go on the right of the top menu bar (kinda
like where tray icons go on macOS).


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

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

Re: Showstopper desktop runtime issue

[Joao De Almeida Pereira]

Hello Hackers

In the PoC we did with Electron last month this was the point where we
stopped

What did we accomplish:
 - Use Electron as a runtime and packaging solution for the application
 - Support opening new windows when the preferences ask for them
 - Make the application generally work
 - Use Chrome as a default browser for the application
 - Building scripts for all platforms using `yarn`, please review Readme
 - The packaged Python version is 3.6 to Mac and Linux, and 3.4 to Windows
 - In our point of view it is a simpler way to generate the installers

Work in progress:
 - No random port for the server, so you can only start 1 instance per
machine
 - Tab support, there is no native support for tabs in Electron. It is
possible to do that, and eventually you will see a option in the menu to
create a new tab, but for this PoC we decided to disable the creation of
tabs. Tabs need to be implemented using HTML and cannot be ripped of from
the current window, like in Chrome
 - Did not test in CentOS, but tested in Ubuntu and it is working (We tried
but the electron required GLIBC 2.25 that was not on the version of CentOS
that we had)
 - In Linux despite the fact that we close the window, the application is
still running and need to be killed by hand
 - We didn't test Debugger opening in new window
 - Loading screen has no reference to pgAdmin
 - No logging file for the runtime
 - Windows we are using python 3.4 and using prior version of psycopg2
2.5.6 and pycrypto 2.6.1 (The version of psycopg2 is not the correct one,
this is because we couldn't find a precompile version of psycopg2)
 - This is just a spike and the code looks pretty messy. This need to be
changed in order to make it more readable and have some tests around it
 - Murtuza and Fahar were not able to run the application in Windows
 - Khushboo was not able to run Ubuntu version

Given this was the status at the time, we need to pick and choose what we
really want to implement right out of the box and what could be postponed.
In order to generate Windows build and ensure that the Linux build is
working we need so help. If we could have access to the machines that you
use to build pgAdmin or access to the venv folder that is generated in
these machines we could try to create a build from that.

The changes we produced still applies cleanly on master and can be found
in: https://github.com/greenplum-db/pgadmin4/tree/electron-over-master

Thanks
Victoria & Joao

On Thu, Mar 22, 2018 at 12:58 PM Dave Page  wrote:

> On Thu, Mar 22, 2018 at 4:28 PM, Dave Page  wrote:
>
>>
>> 2) This option is not very appealing to me, because we would be pilling
 code into the QT portion of the application, that I hope we remove in the
 future, that currently is untested to solve a problem caused by a Window
 Manager..
 I would be more in favor of creating a Application Indicator that would
 support 2 actions, Kill running pgAdmins and launch the browser to access
 them. There is a lot of interesting websites that talk about this, and how
 to develop. I had to download one to have a docker indicator. But as I
 said in a previous thread, I believe that this should be a 3rd party
 application and not a first class citizen on pgAdmin, as the majority of
 the ones that I found are.

>>>
>>> I can't comment on the specific ways to sort it out, but I think
>>> *basing* things in option 2 is by far the best option. If it's just an
>>> additional add-on that can be made a dependency of the packages it's not a
>>> huge problem (provided this add-on is available on the major platforms like
>>> rhel, ubuntu, debian of course)
>>>
>>
>> It would just be a modified version of what we have. Instead of having an
>> icon in the system tray, we'd probably have multiple Start Menu icons to
>> replace the tray icon menu. They would have to signal a running instance to
>> do something, or become a new instance and then do the something if nothing
>> is running already.
>>
>
> Of course, another option here might be to figure out that we're running
> under Gnome/GTK at runtime, and if so, create an indicator icon and menu
> instead of the tray icon. That is, apparently, what Skype and other similar
> apps do now. The indicator icons go on the right of the top menu bar (kinda
> like where tray icons go on macOS).
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: v3.0 release on hold

[Akshay Joshi]

On Thu, Mar 22, 2018 at 10:24 PM, Dave Page  wrote:

> Hi
>
> On Thu, Mar 22, 2018 at 1:13 PM, Dave Page  wrote:
>
>>
>> 2) Starting a second instance of the app bundle on Mac doesn't always
>> open a new pgAdmin window as it should. It works fine in the debugger, or
>> if you start the app with a command like: "/Applications/pgAdmin\
>> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click
>> the appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>>
>
>   Still working on this, not found any solution yet.
>

>>>  Not able to figure out the solution yet. I have tried to debug
>>> the code, but every time it will create a new instance(tray icon). Do I
>>> need to look into the code or something related to app bundle may be some
>>> settings in info.plist or any other pointer?
>>>
>>
>> Have a look at the code around line 85 an onwards of pgAdmin4.cpp. It
>> creates the shared memory interlock (and log/address files) based on the
>> current username and a hash of the executable name/path. My suspicion is
>> that the path hash (which is calculated from argv[0] on line 72) is for
>> some reason getting a different value each time when launched via the
>> Finder or "open", thus the interlock is failing.
>>
>
> So I took a look at this, and it seems the code is just fine. What is
> happening is that macOS only allows a single instance of an app to run at
> once. Whilst that is what we want of course, macOS is causing the new
> instance to exit before it has a change to open a new pgAdmin window. Using
> "open -n ..." or calling the embedded executable directly resolves that
> issue.
>
> So, there's another challenge to figure out... :-(
>

OK. Will try to figure that out.

>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



-- 
*Akshay Joshi*

*Sr. Software Architect *



*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*

Re: v3.0 release on hold

[Khushboo Vashi]

On Thu, Mar 22, 2018 at 3:42 PM, Dave Page  wrote:

>
>
> On Thu, Mar 22, 2018 at 9:58 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Thu, Mar 22, 2018 at 3:20 PM, Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Thu, Mar 22, 2018 at 9:25 AM, Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
 Hi Dave,

 On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:

> We've run into a number of unexpected issues with the v3.0 release
> that I think we need to resolve before moving forwards. For the time 
> being,
> only patches critical to fix these issues should be committed.
>
> I'll try to look at 1, though I do have another deadline I need to
> meet.
> Akshay, can you look at 2 please?
> Fahar is already looking at 3.
> Khushboo, can you look at 4 please?
>
> Thanks all.
>
> 1) There is no longer a system tray in Gnome 3.26 and later, and thus
> the runtime won't initialise in Fedora 27 and later. We need an 
> alternative
> for this, either a tray replacement that the RPM can depend on, or better
> yet, support whatever it is Gnome expect such apps to use these days.
>
> 2) Starting a second instance of the app bundle on Mac doesn't always
> open a new pgAdmin window as it should. It works fine in the debugger, or
> if you start the app with a command like: "/Applications/pgAdmin\
> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click
> the appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>
> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my
> copy, but apparently his is a fresh installation.
>
> 4) On my Windows 7 machine, after running a backup I get no status
> window, and see the following in the logs:
>
>
 We have tried to reproduce this issue on Windows 7 and Windows 8, but
 couldn't reproduce it, It is working fine on both the environments.
 Can you please provide the options which you have selected while taking
 a backup?

>>>
>>> They were all the default options - I just selected a database,
>>> right-clicked to select backup, and entered a filename.
>>>
>>>
>> With the default options, it is working fine.
>>
>
> Can you see any  way in which the exception below could conceivably
> happen? Perhaps if run on a system that has process logs from an older
> version of pgAdmin?
>
>
Not sure as this issue was fixed by Ashesh 1 year back as per git logs.

>
 Traceback (most recent call last):
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
> line 209, in run_wsgi
> execute(self.server.app)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
> line 197, in execute
> application_iter = app(environ, start_response)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1997, in __call__
> return self.wsgi_app(environ, start_response)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1985, in wsgi_app
> response = self.handle_exception(e)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1540, in handle_exception
> reraise(exc_type, exc_value, tb)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1982, in wsgi_app
> response = self.full_dispatch_request()
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1614, in full_dispatch_request
> rv = self.handle_user_exception(e)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1517, in handle_user_exception
> reraise(exc_type, exc_value, tb)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1612, in full_dispatch_request
> rv = self.dispatch_request()
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask\app.py",
> line 1598, in dispatch_request
> return self.view_functions[rule.endpoint](**req.view_args)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\venv\Lib\site-packages\flask_login.py",
> line 792, in decorated_view
> return func(*args, **kwargs)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\web\pgadmin\misc\bgprocess\__init__.py",
> line 62, in index
> return make_response(response=BatchProcess.list())
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\web\pgadmin\misc\bgprocess\processes.py",
> line 584, in list
> details = desc.details(p.command, args)
>   File "C:\Program Files (x86)\pgAdmin 
> 4\v3\web\pgadmin\tools\backup\__init__.py",
>>>

Re: Experiencing issues

[Khushboo Vashi]

Hi,

On Wed, Mar 21, 2018 at 9:31 PM, Dave Page  wrote:

>
>
> On Wed, Mar 21, 2018 at 3:57 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Sorry I did not understand what you said.
>> This configuration:
>>
>> DEFAULT_SERVER = '0.0.0.0'
>> SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>> COOKIE_DEFAULT_DOMAIN = DEFAULT_SERVER
>>
>> If the application lives in the domain pgadmin.somedomain.com do I need
>> to have in config_local:
>> DEFAULT_SERVER = '0.0.0.0'
>> SESSION_COOKIE_DOMAIN = 'pgadmin.somedomain.com'
>> COOKIE_DEFAULT_DOMAIN = 'pgadmin.somedomain.com'
>> ?
>>
>> Does this mean that if for some reason I have a second domain like
>> pgadmin.somedomain2.com that I want to use I cannot?
>>
>> The issue of 127.0.0.1 to localhost is very cumbersome, and somehow we
>> should be able to disable this, because when we are developing doesn't make
>> sense to not being able to use localhost and 127.0.0.1
>>
>
> +1. I didn't realise we'd added this restriction when I tested the patch.
>
> Perhaps a better approach would be to leave the default cookie handling as
> it was, and just expose the domain and path via config options that the
> user can set if appropriate for their installation.
>
> Please find the attached updated patch as discussed.

If one has to set cookie domain and path then below *config variables*
should be changed.

COOKIE_DEFAULT_PATH
COOKIE_DEFAULT_DOMAIN
SESSION_COOKIE_DOMAIN

Thanks,
Khushboo

>
>
>>
>> Thanks
>> Joao
>>
>> On Wed, Mar 21, 2018 at 11:01 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> On Wed, Mar 21, 2018 at 8:27 PM, Joao De Almeida Pereira <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
 So what you are saying is that if I have a server, I need to do
 DEFAULT_SERVER=0.0.0.0 and then set the real domain on the COOKIE domain?

 No I am saying, whatever you set as a DEFAULT_SERVER,  the app can be
>>> accessible with that server.
>>> As, we have explicitly set  DOMAIN in the cookie setting.
>>>
 On Wed, Mar 21, 2018 at 10:55 AM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> On Wed, Mar 21, 2018 at 8:10 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Ok Murtuza you are right,
>> Now my question is I have the default server to 127.0.0.1 and I want
>> to access it using localhost as well. How can I do this?
>>
>> No, you can't.
> Domain based cookie will work for that domain and it's sub-domains.
>
>> On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
>>> I tried that but still nothing. When i check in the inspector for
>>> cookies I have none
>>>
>>> Share your config_local file.
>>>
>>> On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala <
>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>
 Yes, that's cookie related issue (RM#3197), To fix that I added
 below in my config_local.py and it started working again,

 DEFAULT_SERVER = '0.0.0.0'
 COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER

 Clear your browser cookies and server side sessions.


 --
 Regards,
 Murtuza Zabuawala
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company


 On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
 jdealmeidapere...@pivotal.io> wrote:

> Where can I find information about that?
>
> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>> Hello Hackers,
>> Can anyone use the current master branch?
>> When I try to open a server I get a 428. Is that only me?
>>
>> May be because of cookie changes.
>> Check your config.py and config_local.py if you have done changes
>> related to DEFAULT_SERVER in your config_local.py then you need to 
>> change
>> other 2 cookie related variables also.
>>
>> Thanks
>> Joao
>>
>>
>>

>>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
diff --git a/web/config.py b/web/config.py
index 926a87b..ed28438 100644
--- a/web/config.py
+++ b/web/config.py
@@ -252,7 +252,6 @@ SESSION_DB_PATH = os.path.join(DATA_DIR, 'sessions')
 
 SESSION_COOKIE_NAME = 'pga4_session'
 
-SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
 #