Re: [pgadmin-hackers] [pgAdmin4][Patch]: RM1840 - cannot create gist index due to enforced ASC, DESC options in generated SQL

[Surinder Kumar]

Hi Dave,

The last patch was for exclusion constraint only. The same issue issue is
reported RM2061  for index.
So, this patch takes care of both issues.

Added a flag '*is_sort_nulls_applicable*' which is set to true for access
method 'btree'.
If its is true, the values for options 'ASC/DESC' and 'NULLS' are included
in 'create' sql for exclusion and index otherwise not.

Please find updated patch and review.

On Tue, Jan 17, 2017 at 3:43 PM, Dave Page  wrote:

> Hi
>
> On Tue, Jan 17, 2017 at 9:52 AM, Surinder Kumar
>  wrote:
> > Hi
> > On Tue, Jan 17, 2017 at 3:08 PM, Dave Page  wrote:
> >>
> >> Hi
> >>
> >> On Fri, Jan 13, 2017 at 6:50 AM, Surinder Kumar
> >>  wrote:
> >> > Hi
> >> >
> >> > Please find updated patch following changes:
> >> > 1) Keep field 'opclass' combo box enabled.
> >>
> >> That doesn't seem to be working.
>
​It is now fixed in the updated patch.​

> >
> > Is the field 'opclass' is not enabled for you?.
>
> No.
>
> > Can you please tell in which scenario it doesn't gets enabled? so that I
> can
> > fix it.
>
> PostgreSQL 9.4, table:
>
> CREATE TABLE public.foo
> (
> id text COLLATE pg_catalog."default" NOT NULL,
> data1 text COLLATE pg_catalog."default",
> CONSTRAINT foo_pkey1 PRIMARY KEY (id),
> CONSTRAINT gerp1 UNIQUE (id, data1)
> )
>
> 1) Right-click, Create index
>
> 2) Name: 
>
> 3) Access method: gist
>
> 4) Add column. Select id (note the opclass field is not enabled)
>
> 5) Add column. Select data1 (note the opclass field is not enabled).
>
> 6) Click save, and behold the following error in all it's glory :-)
>
> ERROR: data type text has no default operator class for access method
> "gist"
> HINT: You must specify an operator class for the index or define a
> default operator class for the data type.​

​Thanks for steps.​

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


RM1840_V2.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] Patch for RM1911 Direct file navigation [pgAdmin4] [Feature]

[Harshal Dhumal]

Hi,

Pls find updated patch (V7) for direct file navigation with below bug fixes.

-- 
*Harshal Dhumal*
*Software Engineer*

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

On Mon, Jan 16, 2017 at 8:42 PM, Dave Page  wrote:

> Hi
>
> On Sat, Jan 14, 2017 at 2:27 PM, Harshal Dhumal
>  wrote:
> > Hi,
> >
> > Pls updated patch for RM1911.
> >
> > 1. This includes fix for issue index out of range when user enters path
> of
> > folder without trailing slash (showed by Dave).
> > 2. To make this functionality compatible with save last used directory
> > feature.
>
> - The first test I ran gave the error seen in the attachment (running
> in server mode, clicking the Browse button on the backup dialogue).
>
Fixed.


>
> - I also noticed in reviewing the changes again, that you've got code
> in sqleditor/__init__.py to stop the user moving outside of the
> storage sandbox in server mode. That code should be part of the file
> manager - none of the modules using it should be doing that kind of
> check.
>
> Fixed.


> - If I do try to navigate outside of the sandbox, I get a nice error:
> "Error: Access Denied (/Users/dpage/.pgadmin)" for example, if I enter
> /../../. Whilst it's good to be informative, it's also a security
> leak. It should only tell me the path that the user sees, not the path
> as it actually is on the server - e.g.  "Error: Access Denied
> (/../../../)"
>
> Fixed.



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


RM1911_V7_20_Jan.patch
Description: Binary data

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] PATCH: To fix the issue in Database node (pgAdmin4)

[Murtuza Zabuawala]

Let me check

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

On Fri, Jan 20, 2017 at 2:16 AM, George Gelashvili 
wrote:

> Hi Dave and Murtuza,
>
> FYI - on our machines, running the DatabasesUpdateTestCase fails with an
> error after e431eb9d8ecc28572b39d26c9effcf66f70f6ae1:
>
> Traceback (most recent call last):
>   File "/Users/pivotal/workspace/pgadmin4/web/pgadmin/browser/
> server_groups/servers/databases/tests/test_db_put.py", line 58, in runTest
> self.db_id)
>   File "/Users/pivotal/workspace/pgadmin4/web/pgadmin/browser/
> server_groups/servers/databases/tests/utils.py", line 149, in
> disconnect_database
> assert db_con.status_code == 200
> AssertionError
>
> - Tira & George
>
>
> On Mon, Jan 16, 2017 at 10:43 AM, Dave Page  wrote:
>
>> Hi
>>
>> On Fri, Jan 13, 2017 at 10:00 AM, Murtuza Zabuawala
>>  wrote:
>> > Hi Dave,
>> >
>> > I am not able to re-produce it, I reviewed reconnect to database logic
>> and
>> > it is not affected by this patch, Would you please provide me exact
>> steps?
>>
>> Weird, neither can I now. I guess something was messed up in my
>> environment then.
>>
>> Patch applied - sorry for the noise!
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> --
>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgadmin-hackers
>>
>
>

Re: [pgadmin-hackers] Acceptance Tests against a browser (WIP)

[George Gelashvili]

Here's an updated patch which polls to wait for the app to start instead of
sleeping for 10 seconds.

On Thu, Jan 19, 2017 at 5:07 PM, George Gelashvili 
wrote:

>
> Here is an updated patch which starts the server up when the test starts
> and uses the values from config.py for server name etc. It still requires
> installing chromedriver before running. Should we add something to the
> readme about that?
>
> On Tue, Jan 17, 2017 at 11:09 AM, Atira Odhner  wrote:
>
>> Thanks for your feedback, Dave!
>>
>> We can put the tests under the regression directory. I think that makes
>> sense.
>> I'm not picturing these tests being module specific, but we may want to
>> enable running it as a separate suite of tests.
>>
>> Thanks for the callout about the port and title. We'll make sure those
>> are pulled from config or that the pgAdmin server is spun up by the test
>> with specific values.
>>
>> I have a couple ideas about why the test might not have been running for
>> you. I think the patch we attached didn't spin up its own pgAdmin yet and
>> it definitely doesn't fill in username/password if your app is running that
>> way. That's part of the WIP-ness :-P
>>
>> -Tira
>>
>> Hi
>>
>> On Thu, Jan 12, 2017 at 10:41 PM, George Gelashvili
>>  wrote:
>> > here's the patch we forgot to attach. Also, you can see work on our branch
>> > at:
>> > https://github.com/pivotalsoftware/pgadmin4/tree/pivotal/acceptance-tests
>> >
>> > On Thu, Jan 12, 2017 at 5:26 PM, George Gelashvili 
>> > 
>> > wrote:
>> >>
>> >> Hi there,
>> >>
>> >> We are working on browser-automation-based acceptance tests that exercise
>> >> pgAdmin4 the way a user might.
>>
>> Nice!
>>
>> >> The first "connect to database" test works, but at the moment depends on
>> >> Chrome and chromedriver. We would appreciate feedback on any possible
>> >> license or code style issues at this point, as well as any thoughts on
>> >> adding this sort of test to the codebase.
>>
>> A few thoughts:
>>
>> - If these tests are to run as part of the regression suite, the
>> framework for them should live under that directory.
>>
>> - Are any of the tests likely to be module-specific? If so, they
>> should really be part of the relevant module as the regression tests
>> are. If they're more general/less tightly coupled, then I don't see a
>> problem with them residing where they are.
>>
>> - Please take care not to include changes to .gitgnore files that
>> aren't relevant to the rest of us.
>>
>> - The port number is hard-coded in the test.
>>
>> - You've hard-coded the string "pgAdmin 4". We've tried to keep that
>> title as a config option in config.py, so you should pull the string
>> from there rather than hard-coding it.
>>
>> - The connect test fails for me (Mac, Python 2.7). I have a suspicion
>> that this may be because when the test starts chromedriver, OS X
>> prompts the user about whether a listening port should be opened, but
>> the tests don't wait (though, I tested with 3 servers configured and
>> it failed with the same error on the second and third as well, long
>> after I clicked OK on the prompt):
>>
>> Traceback (most recent call last):
>>   File 
>> "/Users/dpage/git/pgadmin4/web/acceptance/test_connects_to_database.py",
>> line 32, in runTest
>> self.assertEqual("pgAdmin 4", self.driver.title)
>> AssertionError: 'pgAdmin 4' != u'localhost'
>>
>> - Please keep tests in the pgadmin. namespace (pgadmin.acceptance.??).
>>
>> - It looks like running a single test won't work yet (because of
>> TestsGeneratorRegistry.load_generators('pgadmin.%s.tests' %
>> arguments['pkg']))
>>
>> Thanks!
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>>
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>>
>
diff --git a/requirements_py2.txt b/requirements_py2.txt
index 51170a45..de167121 100644
--- a/requirements_py2.txt
+++ b/requirements_py2.txt
@@ -36,6 +36,7 @@ testscenarios==0.5.0
 testtools==2.0.0
 traceback2==1.4.0
 unittest2==1.1.0
+selenium==3.0.2
 Werkzeug==0.9.6
 WTForms==2.0.2
 sqlparse==0.1.19
diff --git a/requirements_py3.txt b/requirements_py3.txt
index f68db7a8..9565a6e4 100644
--- a/requirements_py3.txt
+++ b/requirements_py3.txt
@@ -35,6 +35,7 @@ testscenarios==0.5.0
 testtools==2.0.0
 traceback2==1.4.0
 unittest2==1.1.0
+selenium==3.0.2
 Werkzeug==0.9.6
 WTForms==2.0.2
 sqlparse==0.1.19
diff --git a/web/pgadmin/acceptance/__init__.py 
b/web/pgadmin/acceptance/__init__.py
new file mode 100644
index ..e69de29b
diff --git a/web/pgadmin/acceptance/tests/__init__.py 
b/web/pgadmin/acceptance/tests/__init__.py
new file mode 100644
index ..e69de29b
diff --git a/web/pgadmin/acceptance/tests/test_connects_to_database.py 
b/web/pgadmin/acceptance/tests/test_connects_to_database.py
new file mode 100644
index ..2c4f85c4
--- /dev/null
+++ 

[pgadmin-hackers][Patch] Python 3 compatibility

[George Gelashvili]

Hello

We stumbled on the following error when running tests off of master:

Traceback (most recent call last):
  File "web/regression/runtests.py", line 254, in 
servers_info = test_utils.get_config_data()
  File "/Users/pivotal/workspace/pgadmin4/web/regression/test_utils.py",
line 72, in get_config_data
if (not srv.has_key('enabled')) or srv['enabled'] == True:
AttributeError: 'dict' object has no attribute 'has_key'

Please find attached a fix for this.

- George & Tira
diff --git a/web/regression/test_utils.py b/web/regression/test_utils.py
index a2d2f5cd..1f9f0522 100644
--- a/web/regression/test_utils.py
+++ b/web/regression/test_utils.py
@@ -69,7 +69,7 @@ def get_config_data():
 """This function reads the server data from config_data"""
 server_data = []
 for srv in test_setup.config_data['server_credentials']:
-if (not srv.has_key('enabled')) or srv['enabled'] == True:
+if (not 'enabled' in srv) or srv['enabled']:
 data = {"name": srv['name'],
 "comment": srv['comment'],
 "host": srv['host'],

-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-hackers] Acceptance Tests against a browser (WIP)

[George Gelashvili]

Here is an updated patch which starts the server up when the test starts
and uses the values from config.py for server name etc. It still requires
installing chromedriver before running. Should we add something to the
readme about that?

On Tue, Jan 17, 2017 at 11:09 AM, Atira Odhner  wrote:

> Thanks for your feedback, Dave!
>
> We can put the tests under the regression directory. I think that makes
> sense.
> I'm not picturing these tests being module specific, but we may want to
> enable running it as a separate suite of tests.
>
> Thanks for the callout about the port and title. We'll make sure those are
> pulled from config or that the pgAdmin server is spun up by the test with
> specific values.
>
> I have a couple ideas about why the test might not have been running for
> you. I think the patch we attached didn't spin up its own pgAdmin yet and
> it definitely doesn't fill in username/password if your app is running that
> way. That's part of the WIP-ness :-P
>
> -Tira
>
> Hi
>
> On Thu, Jan 12, 2017 at 10:41 PM, George Gelashvili
>  wrote:
> > here's the patch we forgot to attach. Also, you can see work on our branch
> > at:
> > https://github.com/pivotalsoftware/pgadmin4/tree/pivotal/acceptance-tests
> >
> > On Thu, Jan 12, 2017 at 5:26 PM, George Gelashvili 
> > 
> > wrote:
> >>
> >> Hi there,
> >>
> >> We are working on browser-automation-based acceptance tests that exercise
> >> pgAdmin4 the way a user might.
>
> Nice!
>
> >> The first "connect to database" test works, but at the moment depends on
> >> Chrome and chromedriver. We would appreciate feedback on any possible
> >> license or code style issues at this point, as well as any thoughts on
> >> adding this sort of test to the codebase.
>
> A few thoughts:
>
> - If these tests are to run as part of the regression suite, the
> framework for them should live under that directory.
>
> - Are any of the tests likely to be module-specific? If so, they
> should really be part of the relevant module as the regression tests
> are. If they're more general/less tightly coupled, then I don't see a
> problem with them residing where they are.
>
> - Please take care not to include changes to .gitgnore files that
> aren't relevant to the rest of us.
>
> - The port number is hard-coded in the test.
>
> - You've hard-coded the string "pgAdmin 4". We've tried to keep that
> title as a config option in config.py, so you should pull the string
> from there rather than hard-coding it.
>
> - The connect test fails for me (Mac, Python 2.7). I have a suspicion
> that this may be because when the test starts chromedriver, OS X
> prompts the user about whether a listening port should be opened, but
> the tests don't wait (though, I tested with 3 servers configured and
> it failed with the same error on the second and third as well, long
> after I clicked OK on the prompt):
>
> Traceback (most recent call last):
>   File 
> "/Users/dpage/git/pgadmin4/web/acceptance/test_connects_to_database.py",
> line 32, in runTest
> self.assertEqual("pgAdmin 4", self.driver.title)
> AssertionError: 'pgAdmin 4' != u'localhost'
>
> - Please keep tests in the pgadmin. namespace (pgadmin.acceptance.??).
>
> - It looks like running a single test won't work yet (because of
> TestsGeneratorRegistry.load_generators('pgadmin.%s.tests' %
> arguments['pkg']))
>
> Thanks!
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
>
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>
diff --git a/requirements_py2.txt b/requirements_py2.txt
index 51170a45..de167121 100644
--- a/requirements_py2.txt
+++ b/requirements_py2.txt
@@ -36,6 +36,7 @@ testscenarios==0.5.0
 testtools==2.0.0
 traceback2==1.4.0
 unittest2==1.1.0
+selenium==3.0.2
 Werkzeug==0.9.6
 WTForms==2.0.2
 sqlparse==0.1.19
diff --git a/requirements_py3.txt b/requirements_py3.txt
index f68db7a8..9565a6e4 100644
--- a/requirements_py3.txt
+++ b/requirements_py3.txt
@@ -35,6 +35,7 @@ testscenarios==0.5.0
 testtools==2.0.0
 traceback2==1.4.0
 unittest2==1.1.0
+selenium==3.0.2
 Werkzeug==0.9.6
 WTForms==2.0.2
 sqlparse==0.1.19
diff --git a/web/pgadmin/acceptance/__init__.py 
b/web/pgadmin/acceptance/__init__.py
new file mode 100644
index ..e69de29b
diff --git a/web/pgadmin/acceptance/tests/__init__.py 
b/web/pgadmin/acceptance/tests/__init__.py
new file mode 100644
index ..e69de29b
diff --git a/web/pgadmin/acceptance/tests/test_connects_to_database.py 
b/web/pgadmin/acceptance/tests/test_connects_to_database.py
new file mode 100644
index ..ccbcf9f5
--- /dev/null
+++ b/web/pgadmin/acceptance/tests/test_connects_to_database.py
@@ -0,0 +1,108 @@
+#
+#
+# pgAdmin 4 - PostgreSQL Tools
+#
+# Copyright (C) 2013 - 2017, The pgAdmin Development Team
+# This software is released under the PostgreSQL Licence
+#

Re: [pgadmin-hackers] PATCH: To fix the issue in Database node (pgAdmin4)

[George Gelashvili]

Hi Dave and Murtuza,

FYI - on our machines, running the DatabasesUpdateTestCase fails with an
error after e431eb9d8ecc28572b39d26c9effcf66f70f6ae1:

Traceback (most recent call last):
  File
"/Users/pivotal/workspace/pgadmin4/web/pgadmin/browser/server_groups/servers/databases/tests/test_db_put.py",
line 58, in runTest
self.db_id)
  File
"/Users/pivotal/workspace/pgadmin4/web/pgadmin/browser/server_groups/servers/databases/tests/utils.py",
line 149, in disconnect_database
assert db_con.status_code == 200
AssertionError

- Tira & George


On Mon, Jan 16, 2017 at 10:43 AM, Dave Page  wrote:

> Hi
>
> On Fri, Jan 13, 2017 at 10:00 AM, Murtuza Zabuawala
>  wrote:
> > Hi Dave,
> >
> > I am not able to re-produce it, I reviewed reconnect to database logic
> and
> > it is not affected by this patch, Would you please provide me exact
> steps?
>
> Weird, neither can I now. I guess something was messed up in my
> environment then.
>
> Patch applied - sorry for the noise!
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

Re: [pgadmin-hackers] pgadmin4.1.1 ERROR,22021,"invalid byte sequence for encoding ""UTF8""

[Bhanu Gandikota]

Server_encoding: UTF8
Client_encoding: UNICODE

Encoding: UTF8
Collation: en_US.UTF-8
Character type: en_US.UTF-8

From: Murtuza Zabuawala 
Date: Thursday, January 19, 2017 at 12:27 AM
To: Bhanu Gandikota 
Cc: "pgadmin-hackers@postgresql.org" 
Subject: Re: [pgadmin-hackers] pgadmin4.1.1 ERROR,22021,"invalid byte sequence 
for encoding ""UTF8""


  *   SHOW SERVER_ENCODING;
  *   SHOW CLIENT_ENCODING;

[pgadmin-hackers] [PlumAdmin] Desktop vs web app

[Shirley Wang]

Hello,

I am a product designer at Pivotal researching how people use pgAdmin with
Greenplum. The team and I know there's a web app and desktop version of
pgAdmin people can use. Are there different intended use cases for each?

Thanks!

Shirley