Re: [pgadmin4][Patch]: Test cases for the backup module

[Khushboo Vashi]

Hi Victoria,

As per the logs, Restore job is failing only for GPDB. As I don't have
setup for the greenplum database, can you please check this functionality
works well in pgAdmin4 with GPDB?

Thanks,
Khushboo

On Wed, Jun 6, 2018 at 5:13 AM, Victoria Henry  wrote:

> Hi Khushboo
>
> The tests are still failing and seems flaky:
> https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/
> pipelines/pgadmin-patch/jobs/run-tests/builds/113
>
> Sincerely,
>
> Victoria
>
> On Tue, Jun 5, 2018 at 4:50 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Tue, Jun 5, 2018 at 2:09 PM, Dave Page  wrote:
>>
>>>
>>>
>>> On Tue, Jun 5, 2018 at 9:37 AM, Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Tue, Jun 5, 2018 at 1:36 PM, Dave Page  wrote:

> Hi
>
> On Tue, Jun 5, 2018 at 4:39 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Mon, Jun 4, 2018 at 8:41 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Hi Khushboo,
>>>
>>> Some tests are failing in greenplum:
>>> https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/
>>> pipelines/pgadmin-patch/jobs/run-tests/builds/108
>>> The piece of code responsible for the error is:
>>>
>>> if server['default_binary_paths'] is not None:
>>> test_utils.set_preference(server['default_binary_paths'])
>>>
>>> config.DEFAULT_BINARY_PATHS = {
>>> "pg": str(server['default_binary_paths']['pg']),
>>> "ppas": str(server['default_binary_paths']['ppas']),
>>> "gpdb": ""
>>> }
>>>
>>>
>>> Can you send me the test_config.json file?  The above code sets the
>> paths to the SQLite database and through the logs couldn't figure out the
>> exact failure.
>>
>
> It seems clear from the code shown that it's not setting the binary
> paths for gpdb database servers. Shouldn't it be something like:
>
> config.DEFAULT_BINARY_PATHS = {
> "pg": str(server['default_binary_paths']['pg']),
> "ppas": str(server['default_binary_paths']['ppas']),
> "gpdb": str(server['default_binary_paths']['gpdb'])
> }
>
> Without this code, the test cases should work as I already set  paths
 through below code.

 test_utils.set_preference(server['default_binary_paths'])


>>> In that case, why is the code above required at all?
>>>
>>> My bad. Removed this code and also updated set_preference function for
>> greenplum database.
>> Please find the attached updated patch.
>>
>>>
>>>

>
>> test_backup_utils.py file name is misleading, these are not tests,
>>> are helpers.
>>> ​
>>>
>>>
>>> Thanks
>>> Victoria & Joao
>>>
>>> On Mon, Jun 4, 2018 at 1:36 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Sat, Jun 2, 2018 at 3:01 AM, Dave Page 
 wrote:

> Hi
>
> This looks good, except that it's leaving the
> test_restore_database behind. Can we clean that up please?
>
> PFA updated patch.

> Thanks.
>
> On Fri, Jun 1, 2018 at 7:06 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi Victoria,
>>
>> Thanks for reviewing the patch.
>> The tests were failing due to the latest commit #
>> 2b4605a9d390cb44e5dfe9967c3adf2b28d04f1f  - Ensure
>> backup/restore/maintenance work via SSH tunnels. Fixes #3355
>>
>> I have fixed the issues and attached the updated patch.
>>
>> Thanks,
>> Khushboo
>>
>> On Thu, May 31, 2018 at 10:00 PM, Victoria Henry <
>> vhe...@pivotal.io> wrote:
>>
>>> Hi there,
>>>
>>> We've been noticing some issues with the tests on both our CI
>>> and local Mac workstations.
>>>
>>>1. When the following code blocks are invoked - we get
>>>plenty of app.context() issues. It must not be valid when
>>>running tests.
>>>
>>> ​
>>>
>>> from pgadmin.utils.driver import get_driver
>>> driver = get_driver(PG_DEFAULT_DRIVER)
>>> manager = driver.connection_manager(self.sid)
>>>
>>> host = manager.local_bind_host if manager.use_ssh_tunnel else s.host
>>> port = manager.local_bind_port if manager.use_ssh_tunnel else s.port
>>>
>>> 2. When we finally enable
>>>
>>> "default_binary_paths": {
>>>
>>> in our test_config, we get more failing tests that look like:
>>>
>>> ==
>>> FAIL: runTest 
>>> 

Re: [pgadmin4][Patch]: Test cases for the backup module

[Victoria Henry]

Hi Khushboo

The tests are still failing and seems flaky:
https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/pipelines/pgadmin-patch/jobs/run-tests/builds/113

Sincerely,

Victoria

On Tue, Jun 5, 2018 at 4:50 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Tue, Jun 5, 2018 at 2:09 PM, Dave Page  wrote:
>
>>
>>
>> On Tue, Jun 5, 2018 at 9:37 AM, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Tue, Jun 5, 2018 at 1:36 PM, Dave Page  wrote:
>>>
 Hi

 On Tue, Jun 5, 2018 at 4:39 AM, Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On Mon, Jun 4, 2018 at 8:41 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hi Khushboo,
>>
>> Some tests are failing in greenplum:
>>
>> https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/pipelines/pgadmin-patch/jobs/run-tests/builds/108
>> The piece of code responsible for the error is:
>>
>> if server['default_binary_paths'] is not None:
>> test_utils.set_preference(server['default_binary_paths'])
>>
>> config.DEFAULT_BINARY_PATHS = {
>> "pg": str(server['default_binary_paths']['pg']),
>> "ppas": str(server['default_binary_paths']['ppas']),
>> "gpdb": ""
>> }
>>
>>
>> Can you send me the test_config.json file?  The above code sets the
> paths to the SQLite database and through the logs couldn't figure out the
> exact failure.
>

 It seems clear from the code shown that it's not setting the binary
 paths for gpdb database servers. Shouldn't it be something like:

 config.DEFAULT_BINARY_PATHS = {
 "pg": str(server['default_binary_paths']['pg']),
 "ppas": str(server['default_binary_paths']['ppas']),
 "gpdb": str(server['default_binary_paths']['gpdb'])
 }

 Without this code, the test cases should work as I already set  paths
>>> through below code.
>>>
>>> test_utils.set_preference(server['default_binary_paths'])
>>>
>>>
>> In that case, why is the code above required at all?
>>
>> My bad. Removed this code and also updated set_preference function for
> greenplum database.
> Please find the attached updated patch.
>
>>
>>
>>>

> test_backup_utils.py file name is misleading, these are not tests,
>> are helpers.
>> ​
>>
>>
>> Thanks
>> Victoria & Joao
>>
>> On Mon, Jun 4, 2018 at 1:36 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Sat, Jun 2, 2018 at 3:01 AM, Dave Page  wrote:
>>>
 Hi

 This looks good, except that it's leaving the test_restore_database
 behind. Can we clean that up please?

 PFA updated patch.
>>>
 Thanks.

 On Fri, Jun 1, 2018 at 7:06 AM, Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi Victoria,
>
> Thanks for reviewing the patch.
> The tests were failing due to the latest commit
> #2b4605a9d390cb44e5dfe9967c3adf2b28d04f1f  - Ensure
> backup/restore/maintenance work via SSH tunnels. Fixes #3355
>
> I have fixed the issues and attached the updated patch.
>
> Thanks,
> Khushboo
>
> On Thu, May 31, 2018 at 10:00 PM, Victoria Henry <
> vhe...@pivotal.io> wrote:
>
>> Hi there,
>>
>> We've been noticing some issues with the tests on both our CI and
>> local Mac workstations.
>>
>>1. When the following code blocks are invoked - we get plenty
>>of app.context() issues. It must not be valid when running
>>tests.
>>
>> ​
>>
>> from pgadmin.utils.driver import get_driver
>> driver = get_driver(PG_DEFAULT_DRIVER)
>> manager = driver.connection_manager(self.sid)
>>
>> host = manager.local_bind_host if manager.use_ssh_tunnel else s.host
>> port = manager.local_bind_port if manager.use_ssh_tunnel else s.port
>>
>> 2. When we finally enable
>>
>> "default_binary_paths": {
>>
>> in our test_config, we get more failing tests that look like:
>>
>> ==
>> FAIL: runTest 
>> (pgadmin.tools.restore.tests.test_restore_create_job_unit_test.RestoreCreateJobTest)
>> When restore object with option - Miscellaneous
>> --
>> Traceback (most recent call last):
>>   File 
>> "/Users/pivotal/.pyenv/versions/3.6.5/lib/python3.6/unittest/mock.py",
>>  line 1179, in patched
>> return func(*args, **keywargs)
>>   File 
>> 

Re: [pgadmin][patch] Electron version 4.X

[Dave Page]

Hi

On Mon, Jun 4, 2018 at 10:27 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hi Hackers,
>
> Attached you can find the patch that introduces electron to our code base.
>
Cool. FYI, I'd like to get this into rough shape and then push it to a dev
branch for fine-tuning. I think it'll be easier to work that way.


> What do we provide with this patch:
>
>- Start the pgAdmin server from Electron
>- When starting pgAdmin, the user is shown a window that tells them
>that pgAdmin is loading.
>- Once the server has started, the loading window disappears and opens
>pgAdmin in a window
>- Desktop user has the ability to open up new windows to work in.
>- When you close pgAdmin it properly shuts everything down.
>- Stop using copy of web folder for development
>
> I'm not sure what you mean by that last point?


>
>- `
>This is the initial patch for people to start paying around with the
>electron version. There might be things that are not working.
>What we know:
>- Logging is not working on windows
>- We are not packaging any pg_* executables
>- Consistent/Centralized versioning between Electron and pgAdmin Server
>
> OK.

>
>
> We generated builds for:
>
>- MacOs: https://storage.googleapis.com/pgadmin-binaries/pgAdmin-4.0.
>4%2Bdev.darwin.zip
>- Ubuntu/Debian 64 bit: https://storage.googleapis.com
>/pgadmin-binaries/pgAdmin_4.0.4~dev_amd64.linux.zip
>
> 
>- Windows 64 Bit: https://storage.googleapis.com
>/pgadmin-binaries/pgAdmin-4.0.5-dev-windows.zip
>
> 
>- Runtime code is still present
>- Didn’t update the make scripts
>
> We added some instructions on how to build these 3 binaries in
> electron/Readme.md
>
Great. So here's my initial feedback:

- The Mac build you provided doesn't work for me. It hangs on the loading
screen.

- A number of the changes are related to the naming of requirejs. I'd be
inclined to pull that out into a separate patch and get it committed to
master ASAP.

- I think the build instructions need to be more generic (particularly on
macOS). For example, I do not use HomeBrew (largely due to some nasty
security issues they had in the past). I was able to mostly port the
instructions and build script over to work using MacPorts (without PyEnv)
which actually turned out to be somewhat more simple than what's there now.

- I'm not sure what this is intended to do: "git checkout electron".
Clearly that isn't correct.

- All new builds should be using Python 3.6. We need to deprecate 2.7 as
there are some Unicode related issues that cannot be fixed in it.

- The Linux build isn't a Linux build in the general sense - it's a Debian
build and should be named as such (and if we're including that, we should
have a Redhat version - though that needn't hold up the current work).
Sidenote: I'm not sure that either the APT or YUM PostgreSQL projects will
accept a package built in this way as they're somewhat picky about
following platform packaging rules which would mean using the
system-installed Python. I think this is a sane way to go myself, but
that's just my view.

- I would like to see the new build code adapted to follow the existing
conventions as much as reasonable, to avoid having to change build systems
or other processes/procedures that folks use. For example, build scripts
should be under pkg/, completed packages left in dist/, build staging done
in xxx-build directories rather than elsewhere.

- It may be a result of my use of MacPorts, but I'm getting the following
failure building:

yarn run v1.3.2
$ electron-forge make --platfrom=darwin --arch=x64 --targets=dmg
✔ Checking your system
✔ Resolving Forge Config
We need to package your application before we can make it
✔ Preparing to Package Application for arch: x64
⠼ Compiling ApplicationFailed to compile file:
/var/folders/c6/pwf0k2d509s2xx6vh0h633vmgn/T/electron-packager/darwin-x64/pgAdmin-darwin-x64/Electron.app/Contents/Resources/app/venv/lib/python3.6/site-packages/setuptools/command/launcher
manifest.xml
Compiling
/var/folders/c6/pwf0k2d509s2xx6vh0h633vmgn/T/electron-packager/darwin-x64/pgAdmin-darwin-x64/Electron.app/Contents/Resources/app/venv/lib/python3.6/site-packages/setuptools/command/launcher
manifest.xml resulted in a MIME type of application/xml, which we don't
know how to handle
⠋ Compiling ApplicationFailed to compile file:
/var/folders/c6/pwf0k2d509s2xx6vh0h633vmgn/T/electron-packager/darwin-x64/pgAdmin-darwin-x64/Electron.app/Contents/Resources/app/web/pgadmin/browser/server_groups/servers/templates/servers/supported_servers.js

Re: [pgAdmin4][patch] Moved 'Notifications' tab before 'Query History' in Query Tool

[Victoria Henry]

Hi Akshay,

LGTM and passes tests.

Sincerely,

Victoria

On Tue, Jun 5, 2018 at 8:28 AM Akshay Joshi 
wrote:

> Hi Hackers,
>
> Attached is the minor patch to move 'Notifications' tab before "Query
> History" in Query Tool.
>
> --
> *Akshay Joshi*
>
> *Sr. Software Architect *
>
>
>
> *Phone: +91 20-3058-9517Mobile: +91 976-788-8246*
>

Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database.

[Dave Page]

Hi

On Tue, Jun 5, 2018 at 2:03 PM, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi
>
> On Tue, Jun 5, 2018 at 6:25 PM, Dave Page  wrote:
>
>>
>>
>> On Tue, Jun 5, 2018 at 1:49 PM, Aditya Toshniwal <
>> aditya.toshni...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> The problem of SQL ASCII is solved with the patch, and not related to
>>> setting the client encoding of the sql window.
>>>
>>
>> No it's not. It doesn't work for me as I said (and showed the example of).
>>
>
> After setting the client_encoding to SQL_ASCII you got the output.
> Previously, it used to fail in the back end itself because python encoding
> failure. That is fixed.
> The error ERROR:  invalid byte sequence for encoding "UTF8": 0x80 is
> thrown by postgres and not python or pgAdmin4. You will get the same error
> even if you
> connect from psql.
>

Sure - but that is not a fix. You have no way of running the SET command if
you're using "view data" - and in the query tool, users just expect it to
work (as it did in pgAdmin 3).


>
>>
>>> I can see there is no SET call in pgAdmin3 for client_encoding.  I can
>>> remove the SET client_encoding='UNICODE'; that will solve the problem.
>>> But, can you please let me know why that was added.
>>>
>>
>> There is, but it's inside an API call (PQsetClientEncoding):
>>
>> 300
>> 
>> wxLogInfo(wxT("Setting client_encoding to '%s'")
>> , encoding.c_str());
>> 301
>> 
>> if (PQsetClientEncoding(conn, encoding.ToAscii()))
>> 302
>> 
>> {
>> 303
>> 
>> wxLogError(wxT("%s"), GetLastError().c_str());
>> 304
>> 
>> }
>> 305
>> 
>>
>> Oops ! Missed that. Apologies.
>
>>
>>
>>>
>>> Will remove the set call and will send you the updated patch if
>>> everything works fine.
>>>
>>
>> No, we need to ensure the client encoding is set correctly. It just needs
>> to be set to SQL_ASCII if it's a SQL_ASCII database (I believe).
>>
>>
> Need to rework on the initialise method. Will come with an updated. patch.
> Sorry for trouble.
>
>>
>>>
>>> On Tue, Jun 5, 2018 at 6:05 PM, Dave Page  wrote:
>>>
 Hi

 On Tue, Jun 5, 2018 at 1:21 PM, Aditya Toshniwal <
 aditya.toshni...@enterprisedb.com> wrote:

> Hi Dave,
>
>
> On Tue, Jun 5, 2018 at 4:56 PM, Dave Page  wrote:
>
>> Hi
>>
>> On Tue, Jun 5, 2018 at 9:50 AM, Aditya Toshniwal <
>> aditya.toshni...@enterprisedb.com> wrote:
>>
>>> Hi Hackers,
>>>
>>> PFA updated patch. The sqleditor change is sent separately and
>>> removed from current patch as suggested.
>>> The test cases were running fine when the module was specified using
>>> --pkg but were failing in complete run. Fixed that.
>>>
>>
>> I did a quick test by creating a SQL_ASCII database containing a
>> simple table:
>>
>> CREATE TABLE sql_ascii (id serial primary key, data text);
>>
>> And then populated it with data:
>>
>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>> INTO sql_acsii (data) VALUES ('[Windows-1252]   Euro: \x80   Double 
>> dagger:
>> \x87');"
>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>> INTO sql_ascii (data) VALUES ('[Latin-1]   Yen: \xa5   Half: \xbd');"
>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>> INTO sql_ascii (data) VALUES ('[Japanese]   Ship: \xe8\x88\xb9');"
>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>> INTO sql_ascii (data) VALUES ('[Invalid UTF-8]  Blob: 
>> \xf4\xa5\xa3\xa5');"
>>
>> I then right-clicked the table in the treeview, and selected the
>> option to view all rows, and immediately saw an error:
>>
>> 2018-06-05 12:23:27,319: SQL pgadmin: Execute (async) for server #1
>> - CONN:1187535 (Query-id: 8522474):
>> SELECT * FROM public.sql_ascii
>> ORDER BY id ASC
>> 2018-06-05 12:23:27,320: ERROR pgadmin: Failed to execute query
>> (execute_async) for the server #1 - CONN:1187535(Query-id: 8522474):
>> Error Message:ERROR:  invalid byte sequence for encoding "UTF8": 0x80
>> SQL state: 22021
>>
>> Running "SELECT * FROM sql_ascii" in the query tool resulted in the
>> same error, however, if I ran "SET client_encoding = 'SQL_ASCII';" 
>> first, I
>> do see results.
>>
>> I have confirmed that I've restarted the server after applying the

Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database.

[Aditya Toshniwal]

Hi

On Tue, Jun 5, 2018 at 6:25 PM, Dave Page  wrote:

>
>
> On Tue, Jun 5, 2018 at 1:49 PM, Aditya Toshniwal  enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> The problem of SQL ASCII is solved with the patch, and not related to
>> setting the client encoding of the sql window.
>>
>
> No it's not. It doesn't work for me as I said (and showed the example of).
>

After setting the client_encoding to SQL_ASCII you got the output.
Previously, it used to fail in the back end itself because python encoding
failure. That is fixed.
The error ERROR:  invalid byte sequence for encoding "UTF8": 0x80 is thrown
by postgres and not python or pgAdmin4. You will get the same error even if
you
connect from psql.

>
>
>> I can see there is no SET call in pgAdmin3 for client_encoding.  I can
>> remove the SET client_encoding='UNICODE'; that will solve the problem.
>> But, can you please let me know why that was added.
>>
>
> There is, but it's inside an API call (PQsetClientEncoding):
>
> 300
> 
> wxLogInfo(wxT("Setting client_encoding to '%
> s'"), encoding.c_str());
> 301
> 
> if (PQsetClientEncoding(conn, encoding.ToAscii()))
> 302
> 
> {
> 303
> 
> wxLogError(wxT("%s"), GetLastError().c_str());
> 304
> 
> }
> 305
> 
>
> Oops ! Missed that. Apologies.

>
>
>>
>> Will remove the set call and will send you the updated patch if
>> everything works fine.
>>
>
> No, we need to ensure the client encoding is set correctly. It just needs
> to be set to SQL_ASCII if it's a SQL_ASCII database (I believe).
>
>
Need to rework on the initialise method. Will come with an updated. patch.
Sorry for trouble.

>
>>
>> On Tue, Jun 5, 2018 at 6:05 PM, Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Tue, Jun 5, 2018 at 1:21 PM, Aditya Toshniwal <
>>> aditya.toshni...@enterprisedb.com> wrote:
>>>
 Hi Dave,


 On Tue, Jun 5, 2018 at 4:56 PM, Dave Page  wrote:

> Hi
>
> On Tue, Jun 5, 2018 at 9:50 AM, Aditya Toshniwal <
> aditya.toshni...@enterprisedb.com> wrote:
>
>> Hi Hackers,
>>
>> PFA updated patch. The sqleditor change is sent separately and
>> removed from current patch as suggested.
>> The test cases were running fine when the module was specified using
>> --pkg but were failing in complete run. Fixed that.
>>
>
> I did a quick test by creating a SQL_ASCII database containing a
> simple table:
>
> CREATE TABLE sql_ascii (id serial primary key, data text);
>
> And then populated it with data:
>
> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
> INTO sql_acsii (data) VALUES ('[Windows-1252]   Euro: \x80   Double 
> dagger:
> \x87');"
> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
> INTO sql_ascii (data) VALUES ('[Latin-1]   Yen: \xa5   Half: \xbd');"
> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
> INTO sql_ascii (data) VALUES ('[Japanese]   Ship: \xe8\x88\xb9');"
> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
> INTO sql_ascii (data) VALUES ('[Invalid UTF-8]  Blob: \xf4\xa5\xa3\xa5');"
>
> I then right-clicked the table in the treeview, and selected the
> option to view all rows, and immediately saw an error:
>
> 2018-06-05 12:23:27,319: SQL pgadmin: Execute (async) for server #1 -
> CONN:1187535 (Query-id: 8522474):
> SELECT * FROM public.sql_ascii
> ORDER BY id ASC
> 2018-06-05 12:23:27,320: ERROR pgadmin: Failed to execute query
> (execute_async) for the server #1 - CONN:1187535(Query-id: 8522474):
> Error Message:ERROR:  invalid byte sequence for encoding "UTF8": 0x80
> SQL state: 22021
>
> Running "SELECT * FROM sql_ascii" in the query tool resulted in the
> same error, however, if I ran "SET client_encoding = 'SQL_ASCII';" first, 
> I
> do see results.
>
> I have confirmed that I've restarted the server after applying the
> patch.
>
> What am I missing? Why don't we just set the client_encoding to
> SQL_ASCII if it's a SQL_ASCII database?
>

 It is by default same as the server encoding. But, the following
 existing code in  web/pgadmin/utils/driver/psycopg2/connection.py makes
 the client_encoding as UNICODE for every connection. I am not sure it
 should be removed.

 status = _execute(cur, "SET 

Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database.

[Aditya Toshniwal]

Also, there are limitations in psycopg2 as well related to encoding, which
makes it even more difficult to make behaviour similar to pgAdmin3 as there
are encodings and decodings done at pyscopg2 end also.

Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB Software Solutions | Pune
"Don't Complain about Heat, Plant a tree"

On Tue, Jun 5, 2018 at 6:19 PM, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi Dave,
>
> The problem of SQL ASCII is solved with the patch, and not related to
> setting the client encoding of the sql window. I can see there is no SET
> call in pgAdmin3 for client_encoding.  I can remove the SET
> client_encoding='UNICODE'; that will solve the problem. But, can you
> please let me know why that was added.
>
> Will remove the set call and will send you the updated patch if everything
> works fine.
>
>
> Thanks and Regards,
> Aditya Toshniwal
> Software Engineer | EnterpriseDB Software Solutions | Pune
> "Don't Complain about Heat, Plant a tree"
>
> On Tue, Jun 5, 2018 at 6:05 PM, Dave Page  wrote:
>
>> Hi
>>
>> On Tue, Jun 5, 2018 at 1:21 PM, Aditya Toshniwal <
>> aditya.toshni...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>>
>>> On Tue, Jun 5, 2018 at 4:56 PM, Dave Page  wrote:
>>>
 Hi

 On Tue, Jun 5, 2018 at 9:50 AM, Aditya Toshniwal <
 aditya.toshni...@enterprisedb.com> wrote:

> Hi Hackers,
>
> PFA updated patch. The sqleditor change is sent separately and removed
> from current patch as suggested.
> The test cases were running fine when the module was specified using
> --pkg but were failing in complete run. Fixed that.
>

 I did a quick test by creating a SQL_ASCII database containing a simple
 table:

 CREATE TABLE sql_ascii (id serial primary key, data text);

 And then populated it with data:

 /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
 INTO sql_acsii (data) VALUES ('[Windows-1252]   Euro: \x80   Double dagger:
 \x87');"
 /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
 INTO sql_ascii (data) VALUES ('[Latin-1]   Yen: \xa5   Half: \xbd');"
 /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
 INTO sql_ascii (data) VALUES ('[Japanese]   Ship: \xe8\x88\xb9');"
 /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
 INTO sql_ascii (data) VALUES ('[Invalid UTF-8]  Blob: \xf4\xa5\xa3\xa5');"

 I then right-clicked the table in the treeview, and selected the option
 to view all rows, and immediately saw an error:

 2018-06-05 12:23:27,319: SQL pgadmin: Execute (async) for server #1 -
 CONN:1187535 (Query-id: 8522474):
 SELECT * FROM public.sql_ascii
 ORDER BY id ASC
 2018-06-05 12:23:27,320: ERROR pgadmin: Failed to execute query
 (execute_async) for the server #1 - CONN:1187535(Query-id: 8522474):
 Error Message:ERROR:  invalid byte sequence for encoding "UTF8": 0x80
 SQL state: 22021

 Running "SELECT * FROM sql_ascii" in the query tool resulted in the
 same error, however, if I ran "SET client_encoding = 'SQL_ASCII';" first, I
 do see results.

 I have confirmed that I've restarted the server after applying the
 patch.

 What am I missing? Why don't we just set the client_encoding to
 SQL_ASCII if it's a SQL_ASCII database?

>>>
>>> It is by default same as the server encoding. But, the following
>>> existing code in  web/pgadmin/utils/driver/psycopg2/connection.py makes
>>> the client_encoding as UNICODE for every connection. I am not sure it
>>> should be removed.
>>>
>>> status = _execute(cur, "SET DateStyle=ISO;"
>>>
>>>"SET client_min_messages=notice;"
>>>
>>>"SET bytea_output=escape;"
>>>
>>>"SET client_encoding='UNICODE';")
>>>
>>
>> It was probably before you joined, but I have said a number of times that
>> pgAdmin 3 handled this differently and that maybe we should do it the same
>> way here. See https://git.postgresql.org/gitweb/?p=pgadmin3.git;a=blob
>> ;f=pgadmin/db/pgConn.cpp, in the pgConn::Initialize() function.
>>
>> Either way, your patch isn't working for me.
>>
>>
>>>
>>>
>>> Note that this testing was on Python 2.7.10 on MacOS.


>
> Kindly review.
>
> Thanks and Regards,
> Aditya Toshniwal
> Software Engineer | EnterpriseDB Software Solutions | Pune
> "Don't Complain about Heat, Plant a tree"
>
> On Tue, Jun 5, 2018 at 10:15 AM, Aditya Toshniwal <
> aditya.toshni...@enterprisedb.com> wrote:
>
>> Hi
>>
>> On Tue, Jun 5, 2018 at 1:08 AM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Hello Aditya,
>>>


 There is no change related to notifications in this patch.
 The below code is minor fix related 

Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database.

[Aditya Toshniwal]

Hi Dave,

The problem of SQL ASCII is solved with the patch, and not related to
setting the client encoding of the sql window. I can see there is no SET
call in pgAdmin3 for client_encoding.  I can remove the SET
client_encoding='UNICODE'; that will solve the problem. But, can you please
let me know why that was added.

Will remove the set call and will send you the updated patch if everything
works fine.


Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB Software Solutions | Pune
"Don't Complain about Heat, Plant a tree"

On Tue, Jun 5, 2018 at 6:05 PM, Dave Page  wrote:

> Hi
>
> On Tue, Jun 5, 2018 at 1:21 PM, Aditya Toshniwal  enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>>
>> On Tue, Jun 5, 2018 at 4:56 PM, Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Tue, Jun 5, 2018 at 9:50 AM, Aditya Toshniwal <
>>> aditya.toshni...@enterprisedb.com> wrote:
>>>
 Hi Hackers,

 PFA updated patch. The sqleditor change is sent separately and removed
 from current patch as suggested.
 The test cases were running fine when the module was specified using
 --pkg but were failing in complete run. Fixed that.

>>>
>>> I did a quick test by creating a SQL_ASCII database containing a simple
>>> table:
>>>
>>> CREATE TABLE sql_ascii (id serial primary key, data text);
>>>
>>> And then populated it with data:
>>>
>>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>>> INTO sql_acsii (data) VALUES ('[Windows-1252]   Euro: \x80   Double dagger:
>>> \x87');"
>>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>>> INTO sql_ascii (data) VALUES ('[Latin-1]   Yen: \xa5   Half: \xbd');"
>>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>>> INTO sql_ascii (data) VALUES ('[Japanese]   Ship: \xe8\x88\xb9');"
>>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>>> INTO sql_ascii (data) VALUES ('[Invalid UTF-8]  Blob: \xf4\xa5\xa3\xa5');"
>>>
>>> I then right-clicked the table in the treeview, and selected the option
>>> to view all rows, and immediately saw an error:
>>>
>>> 2018-06-05 12:23:27,319: SQL pgadmin: Execute (async) for server #1 -
>>> CONN:1187535 (Query-id: 8522474):
>>> SELECT * FROM public.sql_ascii
>>> ORDER BY id ASC
>>> 2018-06-05 12:23:27,320: ERROR pgadmin: Failed to execute query
>>> (execute_async) for the server #1 - CONN:1187535(Query-id: 8522474):
>>> Error Message:ERROR:  invalid byte sequence for encoding "UTF8": 0x80
>>> SQL state: 22021
>>>
>>> Running "SELECT * FROM sql_ascii" in the query tool resulted in the same
>>> error, however, if I ran "SET client_encoding = 'SQL_ASCII';" first, I do
>>> see results.
>>>
>>> I have confirmed that I've restarted the server after applying the patch.
>>>
>>> What am I missing? Why don't we just set the client_encoding to
>>> SQL_ASCII if it's a SQL_ASCII database?
>>>
>>
>> It is by default same as the server encoding. But, the following existing
>> code in  web/pgadmin/utils/driver/psycopg2/connection.py makes the
>> client_encoding as UNICODE for every connection. I am not sure it should be
>> removed.
>>
>> status = _execute(cur, "SET DateStyle=ISO;"
>>
>>"SET client_min_messages=notice;"
>>
>>"SET bytea_output=escape;"
>>
>>"SET client_encoding='UNICODE';")
>>
>
> It was probably before you joined, but I have said a number of times that
> pgAdmin 3 handled this differently and that maybe we should do it the same
> way here. See https://git.postgresql.org/gitweb/?p=pgadmin3.git;a=
> blob;f=pgadmin/db/pgConn.cpp, in the pgConn::Initialize() function.
>
> Either way, your patch isn't working for me.
>
>
>>
>>
>> Note that this testing was on Python 2.7.10 on MacOS.
>>>
>>>

 Kindly review.

 Thanks and Regards,
 Aditya Toshniwal
 Software Engineer | EnterpriseDB Software Solutions | Pune
 "Don't Complain about Heat, Plant a tree"

 On Tue, Jun 5, 2018 at 10:15 AM, Aditya Toshniwal <
 aditya.toshni...@enterprisedb.com> wrote:

> Hi
>
> On Tue, Jun 5, 2018 at 1:08 AM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hello Aditya,
>>
>>>
>>>
>>> There is no change related to notifications in this patch.
>>> The below code is minor fix related to connection status of sql
>>> editor. Can you please share the code snippet if it is not the below.
>>>
>>> -# Check for the asynchronous notifies statements.
>>> -conn.check_notifies(True)
>>> -notifies = conn.get_notifies()
>>> +if status is not None:
>>> +# Check for the asynchronous notifies statements.
>>> +conn.check_notifies(True)
>>> +notifies = conn.get_notifies()
>>>
>>>
>> This is a minor fix, but is it related to querying SQL_ASCII database?
>>
> No its not. It is 

Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database.

[Dave Page]

Hi

On Tue, Jun 5, 2018 at 1:21 PM, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi Dave,
>
>
> On Tue, Jun 5, 2018 at 4:56 PM, Dave Page  wrote:
>
>> Hi
>>
>> On Tue, Jun 5, 2018 at 9:50 AM, Aditya Toshniwal <
>> aditya.toshni...@enterprisedb.com> wrote:
>>
>>> Hi Hackers,
>>>
>>> PFA updated patch. The sqleditor change is sent separately and removed
>>> from current patch as suggested.
>>> The test cases were running fine when the module was specified using
>>> --pkg but were failing in complete run. Fixed that.
>>>
>>
>> I did a quick test by creating a SQL_ASCII database containing a simple
>> table:
>>
>> CREATE TABLE sql_ascii (id serial primary key, data text);
>>
>> And then populated it with data:
>>
>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>> INTO sql_acsii (data) VALUES ('[Windows-1252]   Euro: \x80   Double dagger:
>> \x87');"
>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>> INTO sql_ascii (data) VALUES ('[Latin-1]   Yen: \xa5   Half: \xbd');"
>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>> INTO sql_ascii (data) VALUES ('[Japanese]   Ship: \xe8\x88\xb9');"
>> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT
>> INTO sql_ascii (data) VALUES ('[Invalid UTF-8]  Blob: \xf4\xa5\xa3\xa5');"
>>
>> I then right-clicked the table in the treeview, and selected the option
>> to view all rows, and immediately saw an error:
>>
>> 2018-06-05 12:23:27,319: SQL pgadmin: Execute (async) for server #1 -
>> CONN:1187535 (Query-id: 8522474):
>> SELECT * FROM public.sql_ascii
>> ORDER BY id ASC
>> 2018-06-05 12:23:27,320: ERROR pgadmin: Failed to execute query
>> (execute_async) for the server #1 - CONN:1187535(Query-id: 8522474):
>> Error Message:ERROR:  invalid byte sequence for encoding "UTF8": 0x80
>> SQL state: 22021
>>
>> Running "SELECT * FROM sql_ascii" in the query tool resulted in the same
>> error, however, if I ran "SET client_encoding = 'SQL_ASCII';" first, I do
>> see results.
>>
>> I have confirmed that I've restarted the server after applying the patch.
>>
>> What am I missing? Why don't we just set the client_encoding to SQL_ASCII
>> if it's a SQL_ASCII database?
>>
>
> It is by default same as the server encoding. But, the following existing
> code in  web/pgadmin/utils/driver/psycopg2/connection.py makes the
> client_encoding as UNICODE for every connection. I am not sure it should be
> removed.
>
> status = _execute(cur, "SET DateStyle=ISO;"
>
>"SET client_min_messages=notice;"
>
>"SET bytea_output=escape;"
>
>"SET client_encoding='UNICODE';")
>

It was probably before you joined, but I have said a number of times that
pgAdmin 3 handled this differently and that maybe we should do it the same
way here. See
https://git.postgresql.org/gitweb/?p=pgadmin3.git;a=blob;f=pgadmin/db/pgConn.cpp,
in the pgConn::Initialize() function.

Either way, your patch isn't working for me.


>
>
> Note that this testing was on Python 2.7.10 on MacOS.
>>
>>
>>>
>>> Kindly review.
>>>
>>> Thanks and Regards,
>>> Aditya Toshniwal
>>> Software Engineer | EnterpriseDB Software Solutions | Pune
>>> "Don't Complain about Heat, Plant a tree"
>>>
>>> On Tue, Jun 5, 2018 at 10:15 AM, Aditya Toshniwal <
>>> aditya.toshni...@enterprisedb.com> wrote:
>>>
 Hi

 On Tue, Jun 5, 2018 at 1:08 AM, Joao De Almeida Pereira <
 jdealmeidapere...@pivotal.io> wrote:

> Hello Aditya,
>
>>
>>
>> There is no change related to notifications in this patch.
>> The below code is minor fix related to connection status of sql
>> editor. Can you please share the code snippet if it is not the below.
>>
>> -# Check for the asynchronous notifies statements.
>> -conn.check_notifies(True)
>> -notifies = conn.get_notifies()
>> +if status is not None:
>> +# Check for the asynchronous notifies statements.
>> +conn.check_notifies(True)
>> +notifies = conn.get_notifies()
>>
>>
> This is a minor fix, but is it related to querying SQL_ASCII database?
>
 No its not. It is something I found when I was working on SQL_ASCII
 related changes.
 Well then, will send a separate patch for it.

>
> Thanks
> Victoria && Joao
>


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

[pgAdmin4][patch] Moved 'Notifications' tab before 'Query History' in Query Tool

[Akshay Joshi]

Hi Hackers,

Attached is the minor patch to move 'Notifications' tab before "Query
History" in Query Tool.

-- 
*Akshay Joshi*

*Sr. Software Architect *



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


Move_Notifications_Tab.patch
Description: Binary data

Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database.

[Aditya Toshniwal]

Hi Dave,


On Tue, Jun 5, 2018 at 4:56 PM, Dave Page  wrote:

> Hi
>
> On Tue, Jun 5, 2018 at 9:50 AM, Aditya Toshniwal  enterprisedb.com> wrote:
>
>> Hi Hackers,
>>
>> PFA updated patch. The sqleditor change is sent separately and removed
>> from current patch as suggested.
>> The test cases were running fine when the module was specified using
>> --pkg but were failing in complete run. Fixed that.
>>
>
> I did a quick test by creating a SQL_ASCII database containing a simple
> table:
>
> CREATE TABLE sql_ascii (id serial primary key, data text);
>
> And then populated it with data:
>
> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT INTO
> sql_acsii (data) VALUES ('[Windows-1252]   Euro: \x80   Double dagger:
> \x87');"
> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT INTO
> sql_ascii (data) VALUES ('[Latin-1]   Yen: \xa5   Half: \xbd');"
> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT INTO
> sql_ascii (data) VALUES ('[Japanese]   Ship: \xe8\x88\xb9');"
> /Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT INTO
> sql_ascii (data) VALUES ('[Invalid UTF-8]  Blob: \xf4\xa5\xa3\xa5');"
>
> I then right-clicked the table in the treeview, and selected the option to
> view all rows, and immediately saw an error:
>
> 2018-06-05 12:23:27,319: SQL pgadmin: Execute (async) for server #1 -
> CONN:1187535 (Query-id: 8522474):
> SELECT * FROM public.sql_ascii
> ORDER BY id ASC
> 2018-06-05 12:23:27,320: ERROR pgadmin: Failed to execute query
> (execute_async) for the server #1 - CONN:1187535(Query-id: 8522474):
> Error Message:ERROR:  invalid byte sequence for encoding "UTF8": 0x80
> SQL state: 22021
>
> Running "SELECT * FROM sql_ascii" in the query tool resulted in the same
> error, however, if I ran "SET client_encoding = 'SQL_ASCII';" first, I do
> see results.
>
> I have confirmed that I've restarted the server after applying the patch.
>
> What am I missing? Why don't we just set the client_encoding to SQL_ASCII
> if it's a SQL_ASCII database?
>

It is by default same as the server encoding. But, the following existing
code in  web/pgadmin/utils/driver/psycopg2/connection.py makes the
client_encoding as UNICODE for every connection. I am not sure it should be
removed.

status = _execute(cur, "SET DateStyle=ISO;"

   "SET client_min_messages=notice;"

   "SET bytea_output=escape;"

   "SET client_encoding='UNICODE';")


Note that this testing was on Python 2.7.10 on MacOS.
>
>
>>
>> Kindly review.
>>
>> Thanks and Regards,
>> Aditya Toshniwal
>> Software Engineer | EnterpriseDB Software Solutions | Pune
>> "Don't Complain about Heat, Plant a tree"
>>
>> On Tue, Jun 5, 2018 at 10:15 AM, Aditya Toshniwal <
>> aditya.toshni...@enterprisedb.com> wrote:
>>
>>> Hi
>>>
>>> On Tue, Jun 5, 2018 at 1:08 AM, Joao De Almeida Pereira <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
 Hello Aditya,

>
>
> There is no change related to notifications in this patch.
> The below code is minor fix related to connection status of sql
> editor. Can you please share the code snippet if it is not the below.
>
> -# Check for the asynchronous notifies statements.
> -conn.check_notifies(True)
> -notifies = conn.get_notifies()
> +if status is not None:
> +# Check for the asynchronous notifies statements.
> +conn.check_notifies(True)
> +notifies = conn.get_notifies()
>
>
 This is a minor fix, but is it related to querying SQL_ASCII database?

>>> No its not. It is something I found when I was working on SQL_ASCII
>>> related changes.
>>> Well then, will send a separate patch for it.
>>>

 Thanks
 Victoria && Joao

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

Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database.

[Dave Page]

Hi

On Tue, Jun 5, 2018 at 9:50 AM, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi Hackers,
>
> PFA updated patch. The sqleditor change is sent separately and removed
> from current patch as suggested.
> The test cases were running fine when the module was specified using --pkg
> but were failing in complete run. Fixed that.
>

I did a quick test by creating a SQL_ASCII database containing a simple
table:

CREATE TABLE sql_ascii (id serial primary key, data text);

And then populated it with data:

/Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT INTO
sql_acsii (data) VALUES ('[Windows-1252]   Euro: \x80   Double dagger:
\x87');"
/Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT INTO
sql_ascii (data) VALUES ('[Latin-1]   Yen: \xa5   Half: \xbd');"
/Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT INTO
sql_ascii (data) VALUES ('[Japanese]   Ship: \xe8\x88\xb9');"
/Library/PostgreSQL/9.4/bin/psql -d sql_ascii -U postgres -c "INSERT INTO
sql_ascii (data) VALUES ('[Invalid UTF-8]  Blob: \xf4\xa5\xa3\xa5');"

I then right-clicked the table in the treeview, and selected the option to
view all rows, and immediately saw an error:

2018-06-05 12:23:27,319: SQL pgadmin: Execute (async) for server #1 -
CONN:1187535 (Query-id: 8522474):
SELECT * FROM public.sql_ascii
ORDER BY id ASC
2018-06-05 12:23:27,320: ERROR pgadmin: Failed to execute query
(execute_async) for the server #1 - CONN:1187535(Query-id: 8522474):
Error Message:ERROR:  invalid byte sequence for encoding "UTF8": 0x80
SQL state: 22021

Running "SELECT * FROM sql_ascii" in the query tool resulted in the same
error, however, if I ran "SET client_encoding = 'SQL_ASCII';" first, I do
see results.

I have confirmed that I've restarted the server after applying the patch.

What am I missing? Why don't we just set the client_encoding to SQL_ASCII
if it's a SQL_ASCII database?

Note that this testing was on Python 2.7.10 on MacOS.


>
> Kindly review.
>
> Thanks and Regards,
> Aditya Toshniwal
> Software Engineer | EnterpriseDB Software Solutions | Pune
> "Don't Complain about Heat, Plant a tree"
>
> On Tue, Jun 5, 2018 at 10:15 AM, Aditya Toshniwal  enterprisedb.com> wrote:
>
>> Hi
>>
>> On Tue, Jun 5, 2018 at 1:08 AM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Hello Aditya,
>>>


 There is no change related to notifications in this patch.
 The below code is minor fix related to connection status of sql editor.
 Can you please share the code snippet if it is not the below.

 -# Check for the asynchronous notifies statements.
 -conn.check_notifies(True)
 -notifies = conn.get_notifies()
 +if status is not None:
 +# Check for the asynchronous notifies statements.
 +conn.check_notifies(True)
 +notifies = conn.get_notifies()


>>> This is a minor fix, but is it related to querying SQL_ASCII database?
>>>
>> No its not. It is something I found when I was working on SQL_ASCII
>> related changes.
>> Well then, will send a separate patch for it.
>>
>>>
>>> Thanks
>>> Victoria && Joao
>>>
>>
>>
>


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

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

pgAdmin 4 commit: Extract the tests and refactor some of the methods.

[Ashesh Vashi]

Extract the tests and refactor some of the methods.

Extract some of the ACI Tree functionalities, and decouple it from the
main source. Also - create some abstractions from the repeated code
around the enable/disable the schema children object create/edit/delete
functionalities, and also created the dialog wrappers for backup and
restore dialogs.

Reviewed by: Khushboo and Ashesh
Refactored by: Ashesh

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=7dd6372eeb3fb2c979fa767afc95d5ee6e2e41ee
Author: Joao De Almeida Pereira 

Modified Files
--
.../schemas/collations/static/js/collation.js  |  34 +-
.../databases/schemas/domains/static/js/domain.js  |  38 +-
.../foreign_tables/static/js/foreign_table.js  |  37 +-
.../static/js/fts_configuration.js |  38 +-
.../fts_dictionaries/static/js/fts_dictionary.js   |  39 +-
.../schemas/fts_parser/static/js/fts_parser.js |  38 +-
.../fts_templates/static/js/fts_template.js|  38 +-
.../schemas/functions/static/js/function.js|  41 +-
.../functions/static/js/trigger_function.js|  40 +-
.../schemas/sequences/static/js/sequence.js|  39 +-
.../servers/databases/schemas/static/js/child.js   |  22 +
.../servers/databases/schemas/static/js/schema.js  |  46 +-
.../schemas/static/js/schema_child_tree_node.js|  41 ++
.../schemas/tables/column/static/js/column.js  |  36 +-
.../check_constraint/static/js/check_constraint.js |   1 -
.../static/js/exclusion_constraint.js  |   1 -
.../foreign_key/static/js/foreign_key.js   |   1 -
.../index_constraint/static/js/primary_key.js  |   1 -
.../static/js/unique_constraint.js |   1 -
.../tables/constraints/static/js/constraints.js|   2 -
.../schemas/tables/indexes/static/js/index.js  |  12 +-
.../tables/partitions/static/js/partition.js   |  68 +--
.../schemas/tables/rules/static/js/rule.js |   2 -
.../tables/static/js/enable_disable_triggers.js|  52 ++
.../databases/schemas/tables/static/js/table.js| 112 +---
.../schemas/tables/triggers/static/js/trigger.js   |  59 +-
.../databases/schemas/types/static/js/type.js  |  41 +-
.../databases/schemas/views/static/js/mview.js |  52 +-
.../databases/schemas/views/static/js/view.js  |  59 +-
web/pgadmin/browser/static/js/collection.js|   8 +-
web/pgadmin/browser/static/js/node.js  |  32 +-
web/pgadmin/static/js/alertify/dialog.js   | 150 +
web/pgadmin/static/js/alertify/dialog_factory.js   |  52 ++
web/pgadmin/static/js/alertify/dialog_wrapper.js   |  57 ++
.../static/js/nodes/supported_database_node.js |  37 ++
web/pgadmin/static/js/tree/pgadmin_tree_node.js|  72 +++
web/pgadmin/static/js/tree/tree.js |  18 +-
web/pgadmin/tools/backup/static/js/backup.js   | 616 +--
.../tools/backup/static/js/backup_dialog.js|  72 +++
.../backup/static/js/backup_dialog_wrapper.js  | 258 
web/pgadmin/tools/backup/static/js/menu_utils.js   |  23 +
web/pgadmin/tools/datagrid/static/js/datagrid.js   | 117 +---
.../tools/datagrid/static/js/get_panel_title.js|  33 +
web/pgadmin/tools/datagrid/static/js/show_data.js  |  92 +++
.../tools/datagrid/static/js/show_query_tool.js|  63 ++
.../tools/grant_wizard/static/js/grant_wizard.js   |  56 +-
.../tools/grant_wizard/static/js/menu_utils.js |  16 +
.../tools/import_export/static/js/import_export.js |  29 +-
.../tools/maintenance/static/js/maintenance.js |  49 +-
.../tools/maintenance/static/js/menu_utils.js  |  13 +
web/pgadmin/tools/restore/static/js/menu_utils.js  |  18 +
web/pgadmin/tools/restore/static/js/restore.js | 389 +---
web/pgadmin/tools/restore/static/js/restore.js.rej | 322 ++
.../tools/restore/static/js/restore_dialog.js  |  57 ++
.../restore/static/js/restore_dialog_wrapper.js| 255 
.../javascript/backup/backup_dialog_spec.js| 205 +++
.../backup/backup_dialog_wrapper_spec.js   | 675 +
.../backup/global_server_backup_dialog_spec.js | 168 +
.../javascript/backup/menu_utils_spec.js   |  55 ++
.../javascript/common_keyboard_shortcuts_spec.js   |   4 -
.../javascript/datagrid/get_panel_title_spec.js|  82 +++
.../javascript/datagrid/show_data_spec.js  | 171 ++
.../javascript/datagrid/show_query_tool_spec.js| 125 
web/regression/javascript/fake_browser/browser.js  |  12 +
web/regression/javascript/fake_endpoints.js|   6 +
web/regression/javascript/fake_model.js|  21 +
.../javascript/nodes/schema/child_menu_spec.js | 253 
.../javascript/restore/restore_dialog_spec.js  | 203 +++
.../restore/restore_dialog_wrapper_spec.js | 593 ++
.../javascript/sqleditor/filter_dialog_specs.js|   2 -
.../table/enable_disable_triggers_spec.js  | 271 +

pgAdmin 4 commit: Handle a potential error case in the connection statu

[Dave Page]

Handle a potential error case in the connection status monitoring.

 When you disconnect the server with an open sqleditor tab, exception
 occurs at the back end. Also, after connecting server, the sqleditor
 is not able to connect back because of the exception.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=920934759f4f608e6b707328e3306099c12f48e1
Author: Aditya Toshniwal 

Modified Files
--
web/pgadmin/tools/sqleditor/__init__.py | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)

Re: [pgAdmin4][patch] sqleditor connection status minor patch

[Dave Page]

Thanks, applied.

On Tue, Jun 5, 2018 at 5:49 AM, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi Hackers,
>
> PFA a minor patch for sqleditor. When you disconnect the server with an
> open sqleditor tab, exception occurs at the back end. Also, after
> connecting server, the sqleditor is not able to connect back because of the
> exception. The patch is to handle it.
> Kindly review.
>
> Thanks and Regards,
> Aditya Toshniwal
> Software Engineer | EnterpriseDB Software Solutions | Pune
> "Don't Complain about Heat, Plant a tree"
>



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

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

pgAdmin 4 commit: Fix constraint on servers table in SQLite to allow po

[Dave Page]

Fix constraint on servers table in SQLite to allow ports < 1024. Fixes #3307

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=20ea8a69f5ef31bc5082dc3d55ef09d1e96dd926
Author: Aditya Toshniwal 

Modified Files
--
web/migrations/versions/7c56ea250085_.py | 90 
web/pgadmin/model/__init__.py|  4 +-
2 files changed, 92 insertions(+), 2 deletions(-)

Re: [pgAdmin4][RM#3307]User interface unable to connect to database running on port range 1-1024

[Dave Page]

Thanks, applied.

On Mon, Jun 4, 2018 at 10:43 AM, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Missed the attachment. Apologies :(
>
> PFA.
>
> Thanks and Regards,
> Aditya Toshniwal
> Software Engineer | EnterpriseDB Software Solutions | Pune
> "Don't Complain about Heat, Plant a tree"
>
> On Mon, Jun 4, 2018 at 3:12 PM, Aditya Toshniwal  enterprisedb.com> wrote:
>
>> Hi Hackers,
>>
>> I missed one part here. There is a constraint on port in in sqlite config
>> database also, and is not allowing ports below 1024.
>> PFA patch - part2 which includes constraint change and migration script
>> for the db file.
>> Kindly review.
>>
>> Thanks and Regards,
>> Aditya Toshniwal
>> Software Engineer | EnterpriseDB Software Solutions | Pune
>> "Don't Complain about Heat, Plant a tree"
>>
>> On Fri, May 18, 2018 at 3:43 PM, Dave Page  wrote:
>>
>>> Thanks, applied.
>>>
>>> On Wed, May 16, 2018 at 2:34 PM, Victoria Henry 
>>> wrote:
>>>
 Hi Aditya,

 Looks good to us!

 Sincerely,

 Anthony & Victoria


 On Wed, May 16, 2018 at 7:24 AM Aditya Toshniwal <
 aditya.toshni...@enterprisedb.com> wrote:

> Hi Hackers,
>
> PFA patch to allow server port number below 1024 till 1 in Create
> Server dialog.
>
> Thanks and Regards,
> Aditya Toshniwal
> Software Engineer | EnterpriseDB Software Solutions | Pune
> "Don't Complain about Heat, Plant a tree"
>

>>>
>>>
>>> --
>>> 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: pgAgent 4.0 patch

[Dave Page]

Thanks, committed with those changes.

Paresh; can you please create some pgAgent 4.0 installers (PG not EPAS
Bitrock installers) from git head for Fahar to test?

Once he's happy with them, I'll tag and build the community packages.

Thanks!

On Tue, Jun 5, 2018 at 5:07 AM, Ashesh Vashi 
wrote:

> On Mon, Jun 4, 2018 at 10:04 PM, Dave Page  wrote:
>
>> Hi
>>
>> Can you review the attached please Ashesh?
>>
> Hi Dave,
>
> Due to the wrong pattern in '.gitignore', it was ignoring the new file
> 'sql/pgagent--3.4--4.0.sql'.
> We should ignore only the '*.sql' in the root directory.
> Something like this.
>
> *$ git diff .gitignore*
> *diff --git a/.gitignore b/.gitignore*
> *index 9883354..40fe7a9 100644*
> *--- a/.gitignore*
> *+++ b/.gitignore*
> *@@ -6,7 +6,12 @@ CPackSourceConfig.cmake*
> * Makefile*
> * cmake_install.cmake*
> * install_manifest.txt*
> *-pgagent*
> *+# Ignore 'pgagent' & 'pgagent.control' in root directory only.*
> *+/pgagent*
> *+!/*/pgagent*
> * pgagent.control*
> *+!/*/pgagent.control*
> * *.log*
> *-*.sql*
> *+# Ignore '*.sql' files in root directory only.*
> *+/*.sql*
> *+!/*/*.sql*
>
>
> And, I am getting the following warning applying the patch.
>
> *$ git apply ~/Downloads/pgagent-4.0-update.diff*
> */Users/asheshvashi/Downloads/pgagent-4.0-update.diff:320: trailing
> whitespace.*
> *//*
> *warning: 1 line adds whitespace errors.*
>
>
> Otherwise - it looks good to me.
>
> --
>
> Thanks & Regards,
>
> Ashesh Vashi
> EnterpriseDB INDIA: Enterprise PostgreSQL Company
> 
>
>
> *http://www.linkedin.com/in/asheshvashi
> *
>
>>
>> Thanks.
>>
>> --
>> 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

pgAgent commit: Updates for 4.0 release

[Dave Page]

Updates for 4.0 release

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgagent.git;a=commitdiff;h=86ca5c5ed1ad572075ba27e05e4680ebdf5b9feb

Modified Files
--
.gitignore   | 13 +++---
CMakeLists.txt   | 12 --
LICENSE  |  2 +-
cmake/MakeExt.cmake  |  2 +-
connection.cpp   |  2 +-
include/connection.h |  2 +-
include/job.h|  2 +-
include/misc.h   |  2 +-
include/pgAgent.h|  2 +-
job.cpp  |  2 +-
misc.cpp |  2 +-
pgAgent.cpp  |  2 +-
pgAgent.rc   | 14 +--
pgaevent/CMakeLists.txt  |  2 +-
pgaevent/pgaevent.c  |  2 +-
pgaevent/pgaevent.def|  2 +-
pgaevent/pgamsgevent.h   |  2 +-
pgaevent/pgamsgevent.rc  |  2 +-
precomp.cpp  |  2 +-
sql/pgagent--3.4--4.0.sql| 19 +++
sql/pgagent--unpackaged--3.4.sql |  2 +-
sql/pgagent.sql  |  6 ++---
sql/pgagent_upgrade.sql  | 52 
unix.cpp |  2 +-
win32.cpp|  2 +-
25 files changed, 63 insertions(+), 91 deletions(-)

Re: [pgAdmin4][RM#3289] Can't query SQL_ASCII database.

[Aditya Toshniwal]

Hi Hackers,

PFA updated patch. The sqleditor change is sent separately and removed from
current patch as suggested.
The test cases were running fine when the module was specified using --pkg
but were failing in complete run. Fixed that.

Kindly review.

Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB Software Solutions | Pune
"Don't Complain about Heat, Plant a tree"

On Tue, Jun 5, 2018 at 10:15 AM, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi
>
> On Tue, Jun 5, 2018 at 1:08 AM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hello Aditya,
>>
>>>
>>>
>>> There is no change related to notifications in this patch.
>>> The below code is minor fix related to connection status of sql editor.
>>> Can you please share the code snippet if it is not the below.
>>>
>>> -# Check for the asynchronous notifies statements.
>>> -conn.check_notifies(True)
>>> -notifies = conn.get_notifies()
>>> +if status is not None:
>>> +# Check for the asynchronous notifies statements.
>>> +conn.check_notifies(True)
>>> +notifies = conn.get_notifies()
>>>
>>>
>> This is a minor fix, but is it related to querying SQL_ASCII database?
>>
> No its not. It is something I found when I was working on SQL_ASCII
> related changes.
> Well then, will send a separate patch for it.
>
>>
>> Thanks
>> Victoria && Joao
>>
>
>


RM3289.patch
Description: Binary data

Re: [pgadmin4][Patch]: Test cases for the backup module

[Dave Page]

On Tue, Jun 5, 2018 at 9:37 AM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Tue, Jun 5, 2018 at 1:36 PM, Dave Page  wrote:
>
>> Hi
>>
>> On Tue, Jun 5, 2018 at 4:39 AM, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Mon, Jun 4, 2018 at 8:41 PM, Joao De Almeida Pereira <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
 Hi Khushboo,

 Some tests are failing in greenplum:
 https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/pipelines
 /pgadmin-patch/jobs/run-tests/builds/108
 The piece of code responsible for the error is:

 if server['default_binary_paths'] is not None:
 test_utils.set_preference(server['default_binary_paths'])

 config.DEFAULT_BINARY_PATHS = {
 "pg": str(server['default_binary_paths']['pg']),
 "ppas": str(server['default_binary_paths']['ppas']),
 "gpdb": ""
 }


 Can you send me the test_config.json file?  The above code sets the
>>> paths to the SQLite database and through the logs couldn't figure out the
>>> exact failure.
>>>
>>
>> It seems clear from the code shown that it's not setting the binary paths
>> for gpdb database servers. Shouldn't it be something like:
>>
>> config.DEFAULT_BINARY_PATHS = {
>> "pg": str(server['default_binary_paths']['pg']),
>> "ppas": str(server['default_binary_paths']['ppas']),
>> "gpdb": str(server['default_binary_paths']['gpdb'])
>> }
>>
>> Without this code, the test cases should work as I already set  paths
> through below code.
>
> test_utils.set_preference(server['default_binary_paths'])
>
>
In that case, why is the code above required at all?



>
>>
>>> test_backup_utils.py file name is misleading, these are not tests, are
 helpers.
 ​


 Thanks
 Victoria & Joao

 On Mon, Jun 4, 2018 at 1:36 AM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On Sat, Jun 2, 2018 at 3:01 AM, Dave Page  wrote:
>
>> Hi
>>
>> This looks good, except that it's leaving the test_restore_database
>> behind. Can we clean that up please?
>>
>> PFA updated patch.
>
>> Thanks.
>>
>> On Fri, Jun 1, 2018 at 7:06 AM, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi Victoria,
>>>
>>> Thanks for reviewing the patch.
>>> The tests were failing due to the latest commit
>>> #2b4605a9d390cb44e5dfe9967c3adf2b28d04f1f  - Ensure
>>> backup/restore/maintenance work via SSH tunnels. Fixes #3355
>>>
>>> I have fixed the issues and attached the updated patch.
>>>
>>> Thanks,
>>> Khushboo
>>>
>>> On Thu, May 31, 2018 at 10:00 PM, Victoria Henry 
>>> wrote:
>>>
 Hi there,

 We've been noticing some issues with the tests on both our CI and
 local Mac workstations.

1. When the following code blocks are invoked - we get plenty
of app.context() issues. It must not be valid when running
tests.

 ​

 from pgadmin.utils.driver import get_driver
 driver = get_driver(PG_DEFAULT_DRIVER)
 manager = driver.connection_manager(self.sid)

 host = manager.local_bind_host if manager.use_ssh_tunnel else s.host
 port = manager.local_bind_port if manager.use_ssh_tunnel else s.port

 2. When we finally enable

 "default_binary_paths": {

 in our test_config, we get more failing tests that look like:

 ==
 FAIL: runTest 
 (pgadmin.tools.restore.tests.test_restore_create_job_unit_test.RestoreCreateJobTest)
 When restore object with option - Miscellaneous
 --
 Traceback (most recent call last):
   File 
 "/Users/pivotal/.pyenv/versions/3.6.5/lib/python3.6/unittest/mock.py", 
 line 1179, in patched
 return func(*args, **keywargs)
   File 
 "/Users/pivotal/workspace/pgadmin4/web/pgadmin/tools/restore/tests/test_restore_create_job_unit_test.py",
  line 295, in runTest
 self.assertEquals(response.status_code, 200)
 AssertionError: 410 != 200

 And

 When restore object with the sections options ... 2018-05-31 
 12:24:42,988: ERRORpgadmin:illegal environment variable name
 Traceback (most recent call last):
   File 
 "/Users/pivotal/workspace/pgadmin4/web/pgadmin/tools/restore/__init__.py",
  line 352, in create_restore_job
 manager.export_password_env(p.id)
   File 
 "/Users/pivotal/workspace/pgadmin4/web/pgadmin/utils/driver/psycopg2/server_manager.py",
  line 

Re: [pgadmin4][Patch]: Test cases for the backup module

[Khushboo Vashi]

On Tue, Jun 5, 2018 at 1:36 PM, Dave Page  wrote:

> Hi
>
> On Tue, Jun 5, 2018 at 4:39 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Mon, Jun 4, 2018 at 8:41 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Hi Khushboo,
>>>
>>> Some tests are failing in greenplum:
>>> https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/pipelines
>>> /pgadmin-patch/jobs/run-tests/builds/108
>>> The piece of code responsible for the error is:
>>>
>>> if server['default_binary_paths'] is not None:
>>> test_utils.set_preference(server['default_binary_paths'])
>>>
>>> config.DEFAULT_BINARY_PATHS = {
>>> "pg": str(server['default_binary_paths']['pg']),
>>> "ppas": str(server['default_binary_paths']['ppas']),
>>> "gpdb": ""
>>> }
>>>
>>>
>>> Can you send me the test_config.json file?  The above code sets the
>> paths to the SQLite database and through the logs couldn't figure out the
>> exact failure.
>>
>
> It seems clear from the code shown that it's not setting the binary paths
> for gpdb database servers. Shouldn't it be something like:
>
> config.DEFAULT_BINARY_PATHS = {
> "pg": str(server['default_binary_paths']['pg']),
> "ppas": str(server['default_binary_paths']['ppas']),
> "gpdb": str(server['default_binary_paths']['gpdb'])
> }
>
> Without this code, the test cases should work as I already set  paths
through below code.

test_utils.set_preference(server['default_binary_paths'])


>
>> test_backup_utils.py file name is misleading, these are not tests, are
>>> helpers.
>>> ​
>>>
>>>
>>> Thanks
>>> Victoria & Joao
>>>
>>> On Mon, Jun 4, 2018 at 1:36 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Sat, Jun 2, 2018 at 3:01 AM, Dave Page  wrote:

> Hi
>
> This looks good, except that it's leaving the test_restore_database
> behind. Can we clean that up please?
>
> PFA updated patch.

> Thanks.
>
> On Fri, Jun 1, 2018 at 7:06 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi Victoria,
>>
>> Thanks for reviewing the patch.
>> The tests were failing due to the latest commit
>> #2b4605a9d390cb44e5dfe9967c3adf2b28d04f1f  - Ensure
>> backup/restore/maintenance work via SSH tunnels. Fixes #3355
>>
>> I have fixed the issues and attached the updated patch.
>>
>> Thanks,
>> Khushboo
>>
>> On Thu, May 31, 2018 at 10:00 PM, Victoria Henry 
>> wrote:
>>
>>> Hi there,
>>>
>>> We've been noticing some issues with the tests on both our CI and
>>> local Mac workstations.
>>>
>>>1. When the following code blocks are invoked - we get plenty of
>>>app.context() issues. It must not be valid when running tests.
>>>
>>> ​
>>>
>>> from pgadmin.utils.driver import get_driver
>>> driver = get_driver(PG_DEFAULT_DRIVER)
>>> manager = driver.connection_manager(self.sid)
>>>
>>> host = manager.local_bind_host if manager.use_ssh_tunnel else s.host
>>> port = manager.local_bind_port if manager.use_ssh_tunnel else s.port
>>>
>>> 2. When we finally enable
>>>
>>> "default_binary_paths": {
>>>
>>> in our test_config, we get more failing tests that look like:
>>>
>>> ==
>>> FAIL: runTest 
>>> (pgadmin.tools.restore.tests.test_restore_create_job_unit_test.RestoreCreateJobTest)
>>> When restore object with option - Miscellaneous
>>> --
>>> Traceback (most recent call last):
>>>   File 
>>> "/Users/pivotal/.pyenv/versions/3.6.5/lib/python3.6/unittest/mock.py", 
>>> line 1179, in patched
>>> return func(*args, **keywargs)
>>>   File 
>>> "/Users/pivotal/workspace/pgadmin4/web/pgadmin/tools/restore/tests/test_restore_create_job_unit_test.py",
>>>  line 295, in runTest
>>> self.assertEquals(response.status_code, 200)
>>> AssertionError: 410 != 200
>>>
>>> And
>>>
>>> When restore object with the sections options ... 2018-05-31 
>>> 12:24:42,988: ERRORpgadmin:illegal environment variable name
>>> Traceback (most recent call last):
>>>   File 
>>> "/Users/pivotal/workspace/pgadmin4/web/pgadmin/tools/restore/__init__.py",
>>>  line 352, in create_restore_job
>>> manager.export_password_env(p.id)
>>>   File 
>>> "/Users/pivotal/workspace/pgadmin4/web/pgadmin/utils/driver/psycopg2/server_manager.py",
>>>  line 365, in export_password_env
>>> os.environ[str(env)] = password
>>>   File "/Users/pivotal/.pyenv/versions/3.6.5/lib/python3.6/os.py", line 
>>> 675, in __setitem__
>>> self.putenv(key, value)
>>> ValueError: illegal environment variable name
>>> FAIL
>>>
>>> ​
>>>

Re: [pgadmin4][Patch]: Test cases for the backup module

[Dave Page]

Hi

On Tue, Jun 5, 2018 at 4:39 AM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Mon, Jun 4, 2018 at 8:41 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hi Khushboo,
>>
>> Some tests are failing in greenplum:
>> https://gpdb-dev.bosh.pivotalci.info/teams/pgadmin/pipelines
>> /pgadmin-patch/jobs/run-tests/builds/108
>> The piece of code responsible for the error is:
>>
>> if server['default_binary_paths'] is not None:
>> test_utils.set_preference(server['default_binary_paths'])
>>
>> config.DEFAULT_BINARY_PATHS = {
>> "pg": str(server['default_binary_paths']['pg']),
>> "ppas": str(server['default_binary_paths']['ppas']),
>> "gpdb": ""
>> }
>>
>>
>> Can you send me the test_config.json file?  The above code sets the paths
> to the SQLite database and through the logs couldn't figure out the exact
> failure.
>

It seems clear from the code shown that it's not setting the binary paths
for gpdb database servers. Shouldn't it be something like:

config.DEFAULT_BINARY_PATHS = {
"pg": str(server['default_binary_paths']['pg']),
"ppas": str(server['default_binary_paths']['ppas']),
"gpdb": str(server['default_binary_paths']['gpdb'])
}




> test_backup_utils.py file name is misleading, these are not tests, are
>> helpers.
>> ​
>>
>>
>> Thanks
>> Victoria & Joao
>>
>> On Mon, Jun 4, 2018 at 1:36 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Sat, Jun 2, 2018 at 3:01 AM, Dave Page  wrote:
>>>
 Hi

 This looks good, except that it's leaving the test_restore_database
 behind. Can we clean that up please?

 PFA updated patch.
>>>
 Thanks.

 On Fri, Jun 1, 2018 at 7:06 AM, Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi Victoria,
>
> Thanks for reviewing the patch.
> The tests were failing due to the latest commit
> #2b4605a9d390cb44e5dfe9967c3adf2b28d04f1f  - Ensure
> backup/restore/maintenance work via SSH tunnels. Fixes #3355
>
> I have fixed the issues and attached the updated patch.
>
> Thanks,
> Khushboo
>
> On Thu, May 31, 2018 at 10:00 PM, Victoria Henry 
> wrote:
>
>> Hi there,
>>
>> We've been noticing some issues with the tests on both our CI and
>> local Mac workstations.
>>
>>1. When the following code blocks are invoked - we get plenty of
>>app.context() issues. It must not be valid when running tests.
>>
>> ​
>>
>> from pgadmin.utils.driver import get_driver
>> driver = get_driver(PG_DEFAULT_DRIVER)
>> manager = driver.connection_manager(self.sid)
>>
>> host = manager.local_bind_host if manager.use_ssh_tunnel else s.host
>> port = manager.local_bind_port if manager.use_ssh_tunnel else s.port
>>
>> 2. When we finally enable
>>
>> "default_binary_paths": {
>>
>> in our test_config, we get more failing tests that look like:
>>
>> ==
>> FAIL: runTest 
>> (pgadmin.tools.restore.tests.test_restore_create_job_unit_test.RestoreCreateJobTest)
>> When restore object with option - Miscellaneous
>> --
>> Traceback (most recent call last):
>>   File 
>> "/Users/pivotal/.pyenv/versions/3.6.5/lib/python3.6/unittest/mock.py", 
>> line 1179, in patched
>> return func(*args, **keywargs)
>>   File 
>> "/Users/pivotal/workspace/pgadmin4/web/pgadmin/tools/restore/tests/test_restore_create_job_unit_test.py",
>>  line 295, in runTest
>> self.assertEquals(response.status_code, 200)
>> AssertionError: 410 != 200
>>
>> And
>>
>> When restore object with the sections options ... 2018-05-31 
>> 12:24:42,988: ERRORpgadmin:illegal environment variable name
>> Traceback (most recent call last):
>>   File 
>> "/Users/pivotal/workspace/pgadmin4/web/pgadmin/tools/restore/__init__.py",
>>  line 352, in create_restore_job
>> manager.export_password_env(p.id)
>>   File 
>> "/Users/pivotal/workspace/pgadmin4/web/pgadmin/utils/driver/psycopg2/server_manager.py",
>>  line 365, in export_password_env
>> os.environ[str(env)] = password
>>   File "/Users/pivotal/.pyenv/versions/3.6.5/lib/python3.6/os.py", line 
>> 675, in __setitem__
>> self.putenv(key, value)
>> ValueError: illegal environment variable name
>> FAIL
>>
>> ​
>>
>> Sincerely,
>>
>> Victoria && Anthony
>>
>> On Thu, May 31, 2018 at 1:16 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> Please find the attached updated patch with the fixes.
>>> The test cases were only failing on MAC not on Linux.
>>>
>>> Thanks,
>>> Khushboo