Обсуждение: [pgAdmin4][Patch]: RM #2963 - Backup database, Restore database and Maintenance Database failed for é object.

Hi,

Please find the attached patch to fix RM #2963: Backup database, Restore database and Maintenance Database failed for é object.

Hi

On Mon, Dec 25, 2017 at 11:03 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

Please find the attached patch to fix RM #2963: Backup database, Restore database and Maintenance Database failed for é object.

With the patch applied, I get:

2018-01-03 15:23:00,110: INFO pgadmin: Executing the process executor with the arguments: ['/Users/dpage/.virtualenvs/pgadmin4/bin/python', '/Users/dpage/git/pgadmin4/web/pgadmin/misc/bgprocess/process_executor.py', '/usr/local/pgsql/bin/pg_dump', u'--file', u'/Users/dpage/e.sql', u'--host', u'localhost', u'--port', '5432', u'--username', u'postgres', u'--no-password', u'--verbose', u'--format=c', u'--blobs', u'\xe9']

2018-01-03 15:23:00,117: INFO werkzeug: 127.0.0.1 - - [03/Jan/2018 15:23:00] "POST /backup/job/1/object HTTP/1.1" 200 -

Exception in thread Thread-6:

Traceback (most recent call last):

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner

    self.run()

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 763, in run

    self.__target(*self.__args, **self.__kwargs)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 602, in process_request_thread

    self.handle_error(request, client_address)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 599, in process_request_thread

    self.finish_request(request, client_address)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 334, in finish_request

    self.RequestHandlerClass(request, client_address, self)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 655, in __init__

    self.handle()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py", line 200, in handle

    rv = BaseHTTPRequestHandler.handle(self)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 340, in handle

    self.handle_one_request()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py", line 235, in handle_one_request

    return self.run_wsgi()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py", line 177, in run_wsgi

    execute(self.server.app)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py", line 165, in execute

    application_iter = app(environ, start_response)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 2000, in __call__

    return self.wsgi_app(environ, start_response)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1991, in wsgi_app

    response = self.make_response(self.handle_exception(e))

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1567, in handle_exception

    reraise(exc_type, exc_value, tb)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1988, in wsgi_app

    response = self.full_dispatch_request()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1641, in full_dispatch_request

    rv = self.handle_user_exception(e)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1544, in handle_user_exception

    reraise(exc_type, exc_value, tb)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1639, in full_dispatch_request

    rv = self.dispatch_request()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1625, in dispatch_request

    return self.view_functions[rule.endpoint](**req.view_args)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask_login.py", line 792, in decorated_view

    return func(*args, **kwargs)

  File "/Users/dpage/git/pgadmin4/web/pgadmin/misc/bgprocess/__init__.py", line 62, in index

    return make_response(response=BatchProcess.list())

  File "/Users/dpage/git/pgadmin4/web/pgadmin/misc/bgprocess/processes.py", line 512, in list

    desc = loads(p.desc)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1381, in loads

    file = StringIO(str)

UnicodeEncodeError: 'ascii' codec can't encode character u'\ufffd' in position 138: ordinal not in range(128) 

--

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

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

On Wed, Jan 3, 2018 at 8:54 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Mon, Dec 25, 2017 at 11:03 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

Please find the attached patch to fix RM #2963: Backup database, Restore database and Maintenance Database failed for é object.

With the patch applied, I get:

2018-01-03 15:23:00,110: INFO pgadmin: Executing the process executor with the arguments: ['/Users/dpage/.virtualenvs/pgadmin4/bin/python', '/Users/dpage/git/pgadmin4/web/pgadmin/misc/bgprocess/process_executor.py', '/usr/local/pgsql/bin/pg_dump', u'--file', u'/Users/dpage/e.sql', u'--host', u'localhost', u'--port', '5432', u'--username', u'postgres', u'--no-password', u'--verbose', u'--format=c', u'--blobs', u'\xe9']

2018-01-03 15:23:00,117: INFO werkzeug: 127.0.0.1 - - [03/Jan/2018 15:23:00] "POST /backup/job/1/object HTTP/1.1" 200 -

Exception in thread Thread-6:

Traceback (most recent call last):

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner

    self.run()

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 763, in run

    self.__target(*self.__args, **self.__kwargs)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 602, in process_request_thread

    self.handle_error(request, client_address)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 599, in process_request_thread

    self.finish_request(request, client_address)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 334, in finish_request

    self.RequestHandlerClass(request, client_address, self)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 655, in __init__

    self.handle()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py", line 200, in handle

    rv = BaseHTTPRequestHandler.handle(self)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 340, in handle

    self.handle_one_request()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py", line 235, in handle_one_request

    return self.run_wsgi()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py", line 177, in run_wsgi

    execute(self.server.app)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py", line 165, in execute

    application_iter = app(environ, start_response)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 2000, in __call__

    return self.wsgi_app(environ, start_response)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1991, in wsgi_app

    response = self.make_response(self.handle_exception(e))

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1567, in handle_exception

    reraise(exc_type, exc_value, tb)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1988, in wsgi_app

    response = self.full_dispatch_request()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1641, in full_dispatch_request

    rv = self.handle_user_exception(e)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1544, in handle_user_exception

    reraise(exc_type, exc_value, tb)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1639, in full_dispatch_request

    rv = self.dispatch_request()

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1625, in dispatch_request

    return self.view_functions[rule.endpoint](**req.view_args)

  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask_login.py", line 792, in decorated_view

    return func(*args, **kwargs)

  File "/Users/dpage/git/pgadmin4/web/pgadmin/misc/bgprocess/__init__.py", line 62, in index

    return make_response(response=BatchProcess.list())

  File "/Users/dpage/git/pgadmin4/web/pgadmin/misc/bgprocess/processes.py", line 512, in list

    desc = loads(p.desc)

  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1381, in loads

    file = StringIO(str)

UnicodeEncodeError: 'ascii' codec can't encode character u'\ufffd' in position 138: ordinal not in range(128) 

Fixed. Please find the attached updated patch. 

Hi,

Please find the attached patch to fix below issues:

1. #2963 - Backup database, Restore database and Maintenance Database failed for é object

2. #3157 - Process viewer doesn't show complete command executed.

Test cases are not included for these fixes as we don't have test cases for these modules (backup, restore, maintenance).

I will create one separate RM for the same which will cover this.

Hi

On Fri, Mar 9, 2018 at 3:54 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

Please find the attached patch to fix below issues:

1. #2963 - Backup database, Restore database and Maintenance Database failed for é object

2. #3157 - Process viewer doesn't show complete command executed.

Test cases are not included for these fixes as we don't have test cases for these modules (backup, restore, maintenance).

I will create one separate RM for the same which will cover this.

Interesting that you fix these together, as together they also exhibit another bug :-). Backing up the é database displays the following command:

/usr/local/pgsql/bin/pg_dump --file "/Users/dpage/foo.bak" --host "localhost" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "&#233;" 

Hi

On Fri, Mar 9, 2018 at 3:32 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Fri, Mar 9, 2018 at 3:54 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

Please find the attached patch to fix below issues:

1. #2963 - Backup database, Restore database and Maintenance Database failed for é object

2. #3157 - Process viewer doesn't show complete command executed.

Test cases are not included for these fixes as we don't have test cases for these modules (backup, restore, maintenance).

I will create one separate RM for the same which will cover this.

Interesting that you fix these together, as together they also exhibit another bug :-). Backing up the é database displays the following command:

/usr/local/pgsql/bin/pg_dump --file "/Users/dpage/foo.bak" --host "localhost" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "&#233;" 

Also, what tests can we add for backup/restore? We have nothing at all at the moment, and it is pretty troublesome. I'd like to ensure that we can backup and restore a database correctly, and ensure that the displayed commands are what we expect and that we get valid output from pg_dump/pg_restore (though, it may change from PG version to PG version, so maybe we should just check for something small and generic). I guess this might need some config parameters for the tests to specify the pg_* utility paths for each server. 

I'd suggest maybe having a feature test that opens the prefs, sets the appropriate path, then runs a backup, waits for it to finish, checks the process monitor output, then restores the same backup to a new database, checking the process monitor output again, and then checking that the restored database contains at least one object from the original database (we don't need to check all of pg_dump/pg_restore, just that something expected was restored). We should use a (partial) database name and backup filename from the advanced test config file, and I think both should default to some interesting non-ASCII strings to ensure quoting works.

--

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

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

Hi Dave,

On Fri, Mar 9, 2018 at 9:09 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Fri, Mar 9, 2018 at 3:32 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Fri, Mar 9, 2018 at 3:54 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

Please find the attached patch to fix below issues:

1. #2963 - Backup database, Restore database and Maintenance Database failed for é object

2. #3157 - Process viewer doesn't show complete command executed.

Test cases are not included for these fixes as we don't have test cases for these modules (backup, restore, maintenance).

I will create one separate RM for the same which will cover this.

Interesting that you fix these together, as together they also exhibit another bug :-). Backing up the é database displays the following command:

/usr/local/pgsql/bin/pg_dump --file "/Users/dpage/foo.bak" --host "localhost" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "&#233;" 

I can reproduce this issue only with notification dialogue (which I have fixed in the attached patch) not with the details dialogue. Please refer the screenshots for the same.

Also, what tests can we add for backup/restore? We have nothing at all at the moment, and it is pretty troublesome. I'd like to ensure that we can backup and restore a database correctly, and ensure that the displayed commands are what we expect and that we get valid output from pg_dump/pg_restore (though, it may change from PG version to PG version, so maybe we should just check for something small and generic). I guess this might need some config parameters for the tests to specify the pg_* utility paths for each server. 

I'd suggest maybe having a feature test that opens the prefs, sets the appropriate path, then runs a backup, waits for it to finish, checks the process monitor output, then restores the same backup to a new database, checking the process monitor output again, and then checking that the restored database contains at least one object from the original database (we don't need to check all of pg_dump/pg_restore, just that something expected was restored). We should use a (partial) database name and backup filename from the advanced test config file, and I think both should default to some interesting non-ASCII strings to ensure quoting works.

I was thinking of writing the unit test cases for the processes.py file as all the major functionalities for backup/restore/maintenance jobs done by this file, but by this we can not achieve the front-end string validation esp for non-ASCII strings.

So, I am thinking of writing feature tests (as you have suggested) first and after that if needed I will write unit test cases.

Hi

On Mon, Mar 12, 2018 at 2:00 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi Dave,

On Fri, Mar 9, 2018 at 9:09 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Fri, Mar 9, 2018 at 3:32 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Fri, Mar 9, 2018 at 3:54 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

Please find the attached patch to fix below issues:

1. #2963 - Backup database, Restore database and Maintenance Database failed for é object

2. #3157 - Process viewer doesn't show complete command executed.

Test cases are not included for these fixes as we don't have test cases for these modules (backup, restore, maintenance).

I will create one separate RM for the same which will cover this.

Interesting that you fix these together, as together they also exhibit another bug :-). Backing up the é database displays the following command:

/usr/local/pgsql/bin/pg_dump --file "/Users/dpage/foo.bak" --host "localhost" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "&#233;" 

I can reproduce this issue only with notification dialogue (which I have fixed in the attached patch) not with the details dialogue. Please refer the screenshots for the same.

Huh, interesting. What Python version were you using? I had 2.7.

 

Also, what tests can we add for backup/restore? We have nothing at all at the moment, and it is pretty troublesome. I'd like to ensure that we can backup and restore a database correctly, and ensure that the displayed commands are what we expect and that we get valid output from pg_dump/pg_restore (though, it may change from PG version to PG version, so maybe we should just check for something small and generic). I guess this might need some config parameters for the tests to specify the pg_* utility paths for each server. 

I'd suggest maybe having a feature test that opens the prefs, sets the appropriate path, then runs a backup, waits for it to finish, checks the process monitor output, then restores the same backup to a new database, checking the process monitor output again, and then checking that the restored database contains at least one object from the original database (we don't need to check all of pg_dump/pg_restore, just that something expected was restored). We should use a (partial) database name and backup filename from the advanced test config file, and I think both should default to some interesting non-ASCII strings to ensure quoting works.

I was thinking of writing the unit test cases for the processes.py file as all the major functionalities for backup/restore/maintenance jobs done by this file, but by this we can not achieve the front-end string validation esp for non-ASCII strings.

So, I am thinking of writing feature tests (as you have suggested) first and after that if needed I will write unit test cases.

Sounds good. Let's try to keep the feature testing minimal, and expand the coverage with unit tests.

Thanks!

--

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

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

So I was trying to test this, and every time I try to run a backup, I'm getting the following, with or without your patch:

(sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings. [SQL: u'INSERT INTO process (pid, user_id, command, "desc", arguments, logdir, start_time, end_time, exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'] [parameters: (180312205250107339, 1, u'/Library/PostgreSQL/9.4/bin/pg_dump', 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.backup\nBackupMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV --file "/Users/dpage/foo.dmp" --host "127.0.0.1" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "\xe9"\np7\nsS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV\xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.', u'--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,--username,postgres,--no-password,--verbose,--format=c,--blobs,\xe9', '/var/lib/pgadmin/sessions/process_logs/180312205250107339', None, None, None, None)]

Any thoughts as to what's going on? I wasn't getting this on my other laptop, and I can't think what else we would have changed to cause this.

On Mon, Mar 12, 2018 at 2:00 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi Dave,

On Fri, Mar 9, 2018 at 9:09 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Fri, Mar 9, 2018 at 3:32 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Fri, Mar 9, 2018 at 3:54 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

Please find the attached patch to fix below issues:

1. #2963 - Backup database, Restore database and Maintenance Database failed for é object

2. #3157 - Process viewer doesn't show complete command executed.

Test cases are not included for these fixes as we don't have test cases for these modules (backup, restore, maintenance).

I will create one separate RM for the same which will cover this.

Interesting that you fix these together, as together they also exhibit another bug :-). Backing up the é database displays the following command:

/usr/local/pgsql/bin/pg_dump --file "/Users/dpage/foo.bak" --host "localhost" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "&#233;" 

I can reproduce this issue only with notification dialogue (which I have fixed in the attached patch) not with the details dialogue. Please refer the screenshots for the same.

Also, what tests can we add for backup/restore? We have nothing at all at the moment, and it is pretty troublesome. I'd like to ensure that we can backup and restore a database correctly, and ensure that the displayed commands are what we expect and that we get valid output from pg_dump/pg_restore (though, it may change from PG version to PG version, so maybe we should just check for something small and generic). I guess this might need some config parameters for the tests to specify the pg_* utility paths for each server. 

I'd suggest maybe having a feature test that opens the prefs, sets the appropriate path, then runs a backup, waits for it to finish, checks the process monitor output, then restores the same backup to a new database, checking the process monitor output again, and then checking that the restored database contains at least one object from the original database (we don't need to check all of pg_dump/pg_restore, just that something expected was restored). We should use a (partial) database name and backup filename from the advanced test config file, and I think both should default to some interesting non-ASCII strings to ensure quoting works.

I was thinking of writing the unit test cases for the processes.py file as all the major functionalities for backup/restore/maintenance jobs done by this file, but by this we can not achieve the front-end string validation esp for non-ASCII strings.

So, I am thinking of writing feature tests (as you have suggested) first and after that if needed I will write unit test cases.

--

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

On 12 Mar 2018, at 23:12, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 2:29 AM, Dave Page <dpage@pgadmin.org> wrote:

So I was trying to test this, and every time I try to run a backup, I'm getting the following, with or without your patch:

(sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings. [SQL: u'INSERT INTO process (pid, user_id, command, "desc", arguments, logdir, start_time, end_time, exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'] [parameters: (180312205250107339, 1, u'/Library/PostgreSQL/9.4/bin/pg_dump', 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.backup\nBackupMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV --file "/Users/dpage/foo.dmp" --host "127.0.0.1" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "\xe9"\np7\nsS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV\xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.', u'--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,--username,postgres,--no-password,--verbose,--format=c,--blobs,\xe9', '/var/lib/pgadmin/sessions/process_logs/180312205250107339', None, None, None, None)]

Any thoughts as to what's going on? I wasn't getting this on my other laptop, and I can't think what else we would have changed to cause this.

Deleting all the records from the process table from SQLITE will solve this problem.

There were few issues related to encoding-decoding in my old patches, you may have applied those.

I deleted the database entirely, and still saw the problem.

On Mon, Mar 12, 2018 at 2:00 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi Dave,

On Fri, Mar 9, 2018 at 9:09 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Fri, Mar 9, 2018 at 3:32 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Fri, Mar 9, 2018 at 3:54 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

Hi,

Please find the attached patch to fix below issues:

1. #2963 - Backup database, Restore database and Maintenance Database failed for é object

2. #3157 - Process viewer doesn't show complete command executed.

Test cases are not included for these fixes as we don't have test cases for these modules (backup, restore, maintenance).

I will create one separate RM for the same which will cover this.

Interesting that you fix these together, as together they also exhibit another bug :-). Backing up the é database displays the following command:

/usr/local/pgsql/bin/pg_dump --file "/Users/dpage/foo.bak" --host "localhost" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "&#233;" 

I can reproduce this issue only with notification dialogue (which I have fixed in the attached patch) not with the details dialogue. Please refer the screenshots for the same.

Also, what tests can we add for backup/restore? We have nothing at all at the moment, and it is pretty troublesome. I'd like to ensure that we can backup and restore a database correctly, and ensure that the displayed commands are what we expect and that we get valid output from pg_dump/pg_restore (though, it may change from PG version to PG version, so maybe we should just check for something small and generic). I guess this might need some config parameters for the tests to specify the pg_* utility paths for each server. 

I'd suggest maybe having a feature test that opens the prefs, sets the appropriate path, then runs a backup, waits for it to finish, checks the process monitor output, then restores the same backup to a new database, checking the process monitor output again, and then checking that the restored database contains at least one object from the original database (we don't need to check all of pg_dump/pg_restore, just that something expected was restored). We should use a (partial) database name and backup filename from the advanced test config file, and I think both should default to some interesting non-ASCII strings to ensure quoting works.

I was thinking of writing the unit test cases for the processes.py file as all the major functionalities for backup/restore/maintenance jobs done by this file, but by this we can not achieve the front-end string validation esp for non-ASCII strings.

So, I am thinking of writing feature tests (as you have suggested) first and after that if needed I will write unit test cases.

--

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

On Tue, Mar 13, 2018 at 9:39 AM, Dave Page <dpage@pgadmin.org> wrote:

On 12 Mar 2018, at 23:12, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 2:29 AM, Dave Page <dpage@pgadmin.org> wrote:

So I was trying to test this, and every time I try to run a backup, I'm getting the following, with or without your patch:

(sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings. [SQL: u'INSERT INTO process (pid, user_id, command, "desc", arguments, logdir, start_time, end_time, exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'] [parameters: (180312205250107339, 1, u'/Library/PostgreSQL/9.4/bin/pg_dump', 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.backup\nBackupMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV --file "/Users/dpage/foo.dmp" --host "127.0.0.1" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "\xe9"\np7\nsS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV\xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.', u'--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,--username,postgres,--no-password,--verbose,--format=c,--blobs,\xe9', '/var/lib/pgadmin/sessions/process_logs/180312205250107339', None, None, None, None)]

Any thoughts as to what's going on? I wasn't getting this on my other laptop, and I can't think what else we would have changed to cause this.

Deleting all the records from the process table from SQLITE will solve this problem.

There were few issues related to encoding-decoding in my old patches, you may have applied those.

I deleted the database entirely, and still saw the problem.

I have tried many things to reproduce this but couldn't.  I faced this issue when I was fixing the issue but not now.

Please make sure to delete the old session and a process table (or database) and apply my latest patch. (of course you do this :) )

I have PY - 2.7.12, psycopg2 - 2.7.4 and SQLAlhemy -1.0.14 to be more specific.

On Tue, Mar 13, 2018 at 12:46 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 9:39 AM, Dave Page <dpage@pgadmin.org> wrote:

On 12 Mar 2018, at 23:12, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 2:29 AM, Dave Page <dpage@pgadmin.org> wrote:

So I was trying to test this, and every time I try to run a backup, I'm getting the following, with or without your patch:

(sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings. [SQL: u'INSERT INTO process (pid, user_id, command, "desc", arguments, logdir, start_time, end_time, exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'] [parameters: (180312205250107339, 1, u'/Library/PostgreSQL/9.4/bin/pg_dump', 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.backup\nBackupMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV --file "/Users/dpage/foo.dmp" --host "127.0.0.1" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "\xe9"\np7\nsS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV\xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.', u'--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,--username,postgres,--no-password,--verbose,--format=c,--blobs,\xe9', '/var/lib/pgadmin/sessions/process_logs/180312205250107339', None, None, None, None)]

Any thoughts as to what's going on? I wasn't getting this on my other laptop, and I can't think what else we would have changed to cause this.

Deleting all the records from the process table from SQLITE will solve this problem.

There were few issues related to encoding-decoding in my old patches, you may have applied those.

I deleted the database entirely, and still saw the problem.

I have tried many things to reproduce this but couldn't.  I faced this issue when I was fixing the issue but not now.

Please make sure to delete the old session and a process table (or database) and apply my latest patch. (of course you do this :) )

I have PY - 2.7.12, psycopg2 - 2.7.4 and SQLAlhemy -1.0.14 to be more specific.

Well I eventually got this to work (basically recreated most of my dev environment), so I committed the patch as it's clearly an improvement.

I can still reproduce the display issue I mentioned though - see the attached screenshot which shows &#233; in a couple of places. I wonder if it's because the database name is just a single character in my tests, whilst you had some other unicode characters in the string?

Can you take a look please?

Thanks.

--

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

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

On Wed, Mar 14, 2018 at 2:18 AM, Dave Page <dpage@pgadmin.org> wrote:

On Tue, Mar 13, 2018 at 12:46 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 9:39 AM, Dave Page <dpage@pgadmin.org> wrote:

On 12 Mar 2018, at 23:12, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 2:29 AM, Dave Page <dpage@pgadmin.org> wrote:

So I was trying to test this, and every time I try to run a backup, I'm getting the following, with or without your patch:

(sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings. [SQL: u'INSERT INTO process (pid, user_id, command, "desc", arguments, logdir, start_time, end_time, exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'] [parameters: (180312205250107339, 1, u'/Library/PostgreSQL/9.4/bin/pg_dump', 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.backup\nBackupMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV --file "/Users/dpage/foo.dmp" --host "127.0.0.1" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "\xe9"\np7\nsS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV\xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.', u'--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,--username,postgres,--no-password,--verbose,--format=c,--blobs,\xe9', '/var/lib/pgadmin/sessions/process_logs/180312205250107339', None, None, None, None)]

Any thoughts as to what's going on? I wasn't getting this on my other laptop, and I can't think what else we would have changed to cause this.

Deleting all the records from the process table from SQLITE will solve this problem.

There were few issues related to encoding-decoding in my old patches, you may have applied those.

I deleted the database entirely, and still saw the problem.

I have tried many things to reproduce this but couldn't.  I faced this issue when I was fixing the issue but not now.

Please make sure to delete the old session and a process table (or database) and apply my latest patch. (of course you do this :) )

I have PY - 2.7.12, psycopg2 - 2.7.4 and SQLAlhemy -1.0.14 to be more specific.

Well I eventually got this to work (basically recreated most of my dev environment), so I committed the patch as it's clearly an improvement.

Thanks. 

I can still reproduce the display issue I mentioned though - see the attached screenshot which shows &#233; in a couple of places. I wonder if it's because the database name is just a single character in my tests, whilst you had some other unicode characters in the string?

I have tested it with a single character also but couldn't reproduce this. Please find the attached screen-shot for the same. 

Can you please take a complete screen shot of the screen (with left side tree and properties panel of the database) and send it?

Hi

On Tue, Mar 13, 2018 at 11:18 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Wed, Mar 14, 2018 at 2:18 AM, Dave Page <dpage@pgadmin.org> wrote:

On Tue, Mar 13, 2018 at 12:46 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 9:39 AM, Dave Page <dpage@pgadmin.org> wrote:

On 12 Mar 2018, at 23:12, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 2:29 AM, Dave Page <dpage@pgadmin.org> wrote:

So I was trying to test this, and every time I try to run a backup, I'm getting the following, with or without your patch:

(sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings. [SQL: u'INSERT INTO process (pid, user_id, command, "desc", arguments, logdir, start_time, end_time, exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'] [parameters: (180312205250107339, 1, u'/Library/PostgreSQL/9.4/bin/pg_dump', 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.backup\nBackupMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV --file "/Users/dpage/foo.dmp" --host "127.0.0.1" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "\xe9"\np7\nsS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV\xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.', u'--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,--username,postgres,--no-password,--verbose,--format=c,--blobs,\xe9', '/var/lib/pgadmin/sessions/process_logs/180312205250107339', None, None, None, None)]

Any thoughts as to what's going on? I wasn't getting this on my other laptop, and I can't think what else we would have changed to cause this.

Deleting all the records from the process table from SQLITE will solve this problem.

There were few issues related to encoding-decoding in my old patches, you may have applied those.

I deleted the database entirely, and still saw the problem.

I have tried many things to reproduce this but couldn't.  I faced this issue when I was fixing the issue but not now.

Please make sure to delete the old session and a process table (or database) and apply my latest patch. (of course you do this :) )

I have PY - 2.7.12, psycopg2 - 2.7.4 and SQLAlhemy -1.0.14 to be more specific.

Well I eventually got this to work (basically recreated most of my dev environment), so I committed the patch as it's clearly an improvement.

Thanks. 

I can still reproduce the display issue I mentioned though - see the attached screenshot which shows &#233; in a couple of places. I wonder if it's because the database name is just a single character in my tests, whilst you had some other unicode characters in the string?

I have tested it with a single character also but couldn't reproduce this. Please find the attached screen-shot for the same. 

Can you please take a complete screen shot of the screen (with left side tree and properties panel of the database) and send it?

Sure - attached. 

--

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

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

On Thu, Mar 15, 2018 at 3:13 AM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Tue, Mar 13, 2018 at 11:18 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Wed, Mar 14, 2018 at 2:18 AM, Dave Page <dpage@pgadmin.org> wrote:

On Tue, Mar 13, 2018 at 12:46 AM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 9:39 AM, Dave Page <dpage@pgadmin.org> wrote:

On 12 Mar 2018, at 23:12, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Tue, Mar 13, 2018 at 2:29 AM, Dave Page <dpage@pgadmin.org> wrote:

So I was trying to test this, and every time I try to run a backup, I'm getting the following, with or without your patch:

(sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings. [SQL: u'INSERT INTO process (pid, user_id, command, "desc", arguments, logdir, start_time, end_time, exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)'] [parameters: (180312205250107339, 1, u'/Library/PostgreSQL/9.4/bin/pg_dump', 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.backup\nBackupMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV --file "/Users/dpage/foo.dmp" --host "127.0.0.1" --port "5432" --username "postgres" --no-password --verbose --format=c --blobs "\xe9"\np7\nsS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV\xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.', u'--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,--username,postgres,--no-password,--verbose,--format=c,--blobs,\xe9', '/var/lib/pgadmin/sessions/process_logs/180312205250107339', None, None, None, None)]

Any thoughts as to what's going on? I wasn't getting this on my other laptop, and I can't think what else we would have changed to cause this.

Deleting all the records from the process table from SQLITE will solve this problem.

There were few issues related to encoding-decoding in my old patches, you may have applied those.

I deleted the database entirely, and still saw the problem.

I have tried many things to reproduce this but couldn't.  I faced this issue when I was fixing the issue but not now.

Please make sure to delete the old session and a process table (or database) and apply my latest patch. (of course you do this :) )

I have PY - 2.7.12, psycopg2 - 2.7.4 and SQLAlhemy -1.0.14 to be more specific.

Well I eventually got this to work (basically recreated most of my dev environment), so I committed the patch as it's clearly an improvement.

Thanks. 

I can still reproduce the display issue I mentioned though - see the attached screenshot which shows &#233; in a couple of places. I wonder if it's because the database name is just a single character in my tests, whilst you had some other unicode characters in the string?

I have tested it with a single character also but couldn't reproduce this. Please find the attached screen-shot for the same. 

Can you please take a complete screen shot of the screen (with left side tree and properties panel of the database) and send it?

Sure - attached. 

 

I didn't find any root cause as the below line responsible for un-escaping the html and it is clearly shown that it is not happening in your case. 

$header.find('.bg-detailed-desc').html(_.unescape(self.detailed_desc));