Re: pgAdmin IV API test cases patch - Mailing list pgadmin-hackers

From Khushboo Vashi
Subject Re: pgAdmin IV API test cases patch
Date
Msg-id CAFOhELdqD6+RD_4EmpS7nAYwq5OpJH78CZiq1yo3xrr9hk00BA@mail.gmail.com
Whole thread Raw
In response to Re: pgAdmin IV API test cases patch  (Priyanka Shendge <priyanka.shendge@enterprisedb.com>)
Responses Re: pgAdmin IV API test cases patch  (Dave Page <dpage@pgadmin.org>)
List pgadmin-hackers


On Mon, Jul 11, 2016 at 7:15 PM, Priyanka Shendge <priyanka.shendge@enterprisedb.com> wrote:


On 11 July 2016 at 18:35, Dave Page <dpage@pgadmin.org> wrote:
On Mon, Jul 11, 2016 at 1:25 PM, Priyanka Shendge
<priyanka.shendge@enterprisedb.com> wrote:
> Sorry, by mistake i copied incomplete query.  There is an OID present for
> added database.
>
> SELECT
>     db.oid as did, db.datname, db.datallowconn,
>     pg_encoding_to_char(db.encoding) AS serverencoding,
>     has_database_privilege(db.oid, 'CREATE') as cancreate, datlastsysoid
> FROM
>     pg_database db
> WHERE db.oid = 158579

There's nothing wrong with that query. Can you work with Khushboo to
see if she can reproduce or help figure it out please?

I had work with Khushboo, she also tried to reproduce the issue at her it's working fine for her.
Khushboo also tried to troubleshoot/trace the issue but not able to figure out where exactly its failing;
as issue was not reproducible.

@Khushboo:
 Please add if i am missing anything.



We have tried to reproduce this issue at our end several times with the different scenarios but every attempt was unsuccessful.

Here the newly created database connection is failing which should not as the database is created properly as per the log.
The above query (mentioned by Priyanka) executes from the psycopg2 driver and could fail in 2 scenarios, either the database has been dropped before this particular test-case runs or the database is not created properly through the 'create database test-case'.  But as per the log, the 'delete database test-case' runs after this test-case and the database is created properly.

Can any privilege issue prevent the database connection in this scenario?

Thanks,
Khushboo


 
Thanks.

> On 11 July 2016 at 17:18, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi,
>>
>> No, sorry I don't have an extra system you can test on.
>>
>> It's pretty clear that query would fail - it's missing a database OID
>> after the =
>>
>> On Fri, Jul 8, 2016 at 10:38 AM, Priyanka Shendge
>> <priyanka.shendge@enterprisedb.com> wrote:
>> > Hi Dave,
>> >
>> > I have tried to reproduce the issue by running the test-suite on
>> > different
>> > machines (64 and 32 bit) and
>> > users on PG9.4/9.5 (Provided different "test_db_username" in
>> > test_config.json). It is working fine at my end.
>> >
>> > The log file (output.log) sent by you shows following query is failing
>> > at
>> > your end:
>> >
>> > SELECT
>> >     db.oid as did, db.datname, db.datallowconn,
>> >     pg_encoding_to_char(db.encoding) AS serverencoding,
>> >     has_database_privilege(db.oid, 'CREATE') as cancreate, datlastsysoid
>> > FROM
>> >     pg_database db
>> > WHERE db.oid =
>> >
>> > Let me know if you have an extra system where I can reproduce the issue.
>> >
>> >
>> > On 5 July 2016 at 15:40, Dave Page <dpage@pgadmin.org> wrote:
>> >>
>> >> Attached.
>> >>
>> >> On Tue, Jul 5, 2016 at 9:00 AM, Priyanka Shendge
>> >> <priyanka.shendge@enterprisedb.com> wrote:
>> >> > Hi Dave,
>> >> >
>> >> > I tried running the testsuite against PG9.4 and unable to reproduce
>> >> > the
>> >> > failures.
>> >> > I have added debug statements to previous patch. Patch attached.
>> >> > Could you please re-run the same and send me the logs and output?
>> >> >
>> >> > Thank you.
>> >> >
>> >> > On 4 July 2016 at 17:30, Dave Page <dpage@pgadmin.org> wrote:
>> >> >>
>> >> >> Hi
>> >> >>
>> >> >> The test data was the default, and I ran against PG 9.4. All other
>> >> >> logs
>> >> >> were attached to my previous email.
>> >> >>
>> >> >> --
>> >> >> Dave Page
>> >> >> Blog: http://pgsnake.blogspot.com
>> >> >> Twitter: @pgsnake
>> >> >>
>> >> >> EnterpriseDB UK:http://www.enterprisedb.com
>> >> >> The Enterprise PostgreSQL Company
>> >> >>
>> >> >> On 4 Jul 2016, at 12:16, Priyanka Shendge
>> >> >> <priyanka.shendge@enterprisedb.com> wrote:
>> >> >>
>> >> >> Hi Dave,
>> >> >>
>> >> >> I am unable to reproduce issue on my side; tried on Python 2.7 and
>> >> >> Python
>> >> >> 3.4.
>> >> >> Could you please provide me DEBUG logs and test data using for
>> >> >> database
>> >> >> node?
>> >> >>
>> >> >> Thank you.
>> >> >>
>> >> >> On 30 June 2016 at 00:51, Dave Page <dpage@pgadmin.org> wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> That's better. I tweaked a few things and fixed a bug related to
>> >> >>> recent changes to the schema version config. Patch attached.
>> >> >>>
>> >> >>> However, there are still issues:
>> >> >>>
>> >> >>> 1) The testsuite doesn't run to completion. See the attached
>> >> >>> stdout.txt and logger.txt files.
>> >> >>> 2) stdout should only display the test summary - what tests are
>> >> >>> currently running (and pass/fail), and a summary at the end - even
>> >> >>> if
>> >> >>> there's a crash like I saw.
>> >> >>> 3) The output log file should contain the full output, including
>> >> >>> what's sent to stdout.
>> >> >>> 4) The output advises the user to check
>> >> >>> ".../pgadmin4/web/regression".
>> >> >>> This should be in the summary at the end, and should be corrected
>> >> >>> to
>> >> >>> show the correct (full) path.
>> >> >>>
>> >> >>> Thanks.
>> >> >>>
>> >> >>>
>> >> >>> On Wed, Jun 29, 2016 at 2:52 PM, Priyanka Shendge
>> >> >>> <priyanka.shendge@enterprisedb.com> wrote:
>> >> >>> > Hi Dave,
>> >> >>> >
>> >> >>> > As per discussion over mail i have created separate config files
>> >> >>> > for
>> >> >>> > credentials and test data.
>> >> >>> >
>> >> >>> > PFA patch for same. Kindly, review and let me know for
>> >> >>> > modifications.
>> >> >>> >
>> >> >>> > On 27 June 2016 at 15:10, Priyanka Shendge
>> >> >>> > <priyanka.shendge@enterprisedb.com> wrote:
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> On 27 June 2016 at 13:24, Dave Page <dpage@pgadmin.org> wrote:
>> >> >>> >>>
>> >> >>> >>> On Sun, Jun 26, 2016 at 12:05 PM, Priyanka Shendge
>> >> >>> >>> <priyanka.shendge@enterprisedb.com> wrote:
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > On 24 June 2016 at 16:17, Dave Page <dpage@pgadmin.org>
>> >> >>> >>> > wrote:
>> >> >>> >>> >>
>> >> >>> >>> >> Hi
>> >> >>> >>> >>
>> >> >>> >>> >> On Thu, Jun 23, 2016 at 2:41 PM, Priyanka Shendge
>> >> >>> >>> >> <priyanka.shendge@enterprisedb.com> wrote:
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> > On 15 June 2016 at 15:05, Priyanka Shendge
>> >> >>> >>> >> > <priyanka.shendge@enterprisedb.com> wrote:
>> >> >>> >>> >> >>
>> >> >>> >>> >> >> Thanks a lot Dave.
>> >> >>> >>> >> >>
>> >> >>> >>> >> >> On 15 June 2016 at 14:09, Dave Page <dpage@pgadmin.org>
>> >> >>> >>> >> >> wrote:
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> Hi
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> On Thu, Jun 9, 2016 at 1:37 PM, Priyanka Shendge
>> >> >>> >>> >> >>> <priyanka.shendge@enterprisedb.com> wrote:
>> >> >>> >>> >> >>> > Hi Dave,
>> >> >>> >>> >> >>> >
>> >> >>> >>> >> >>> > PFA updated patch. I have made changes suggested by
>> >> >>> >>> >> >>> > you.
>> >> >>> >>> >> >>> >
>> >> >>> >>> >> >>> > Kindly, review and let me know for more changes.
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> OK, I got a bit further this time, but not there yet.
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> 1) The patch overwrote my test_config.json file. That
>> >> >>> >>> >> >>> should
>> >> >>> >>> >> >>> never
>> >> >>> >>> >> >>> happen (that file shouldn't be in the source tree).
>> >> >>> >>> >> >>> test_config.json.in should be the file that's included
>> >> >>> >>> >> >>> in
>> >> >>> >>> >> >>> the
>> >> >>> >>> >> >>> patch.
>> >> >>> >>> >> >>
>> >> >>> >>> >> >>
>> >> >>> >>> >> >> OK.
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>>
>> >> >>> >>> >> >>> 2) The updated test_config.json file is huge.
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> > Current configuration file web/regression/test_config.json
>> >> >>> >>> >> > contains
>> >> >>> >>> >> > test
>> >> >>> >>> >> > data(credentials) for each tree node;
>> >> >>> >>> >> > which is used while adding and updating the respective
>> >> >>> >>> >> > node.
>> >> >>> >>> >>
>> >> >>> >>> >> Why would we need that?
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > Each node file (e.g. test_db_add.py and test_db_put.py) uses
>> >> >>> >>> > respective
>> >> >>> >>> > credentials test data  from
>> >> >>> >>> > test_config.json while execution.
>> >> >>> >>>
>> >> >>> >>> That doesn't answer my question - why do we need separate
>> >> >>> >>> credentials
>> >> >>> >>> for each node?
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> Sorry for typo, its test data not credentials.
>> >> >>> >>
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> >> We should have just one set of credentials for
>> >> >>> >>> >> everything.
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > Let me know if my understanding is clear:
>> >> >>> >>> >
>> >> >>> >>> > Should i keep basic credentials of each node (database,
>> >> >>> >>> > schema)
>> >> >>> >>> > into
>> >> >>> >>> > test_config.json
>> >> >>> >>> > instead  taking care of each field?
>> >> >>> >>>
>> >> >>> >>> You should have one set of credentials that's used for the
>> >> >>> >>> entire
>> >> >>> >>> test
>> >> >>> >>> run.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> Sure.  I'll separate the credentials and test data into 2
>> >> >>> >> different
>> >> >>> >> files.
>> >> >>> >> So, a normal user can run the tests into one go after some minor
>> >> >>> >> credentials changes.
>> >> >>> >> And an advanced user can have an option to change the test data
>> >> >>> >> if
>> >> >>> >> he
>> >> >>> >> wants.
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> >> >>> I should only need to
>> >> >>> >>> >> >>> define one or more connections, then be able to run the
>> >> >>> >>> >> >>> tests.
>> >> >>> >>> >> >>> If
>> >> >>> >>> >> >>> you
>> >> >>> >>> >> >>> need to keep configuration info for "advanced users",
>> >> >>> >>> >> >>> let's
>> >> >>> >>> >> >>> put it
>> >> >>> >>> >> >>> in
>> >> >>> >>> >> >>> a different file to avoid confusing/scaring everyone
>> >> >>> >>> >> >>> else.
>> >> >>> >>> >> >>> Maybe
>> >> >>> >>> >> >>> split
>> >> >>> >>> >> >>> it into config.json for the stuff the user needs to edit
>> >> >>> >>> >> >>> (config.json.in would go in git), and test_config.json
>> >> >>> >>> >> >>> for
>> >> >>> >>> >> >>> the
>> >> >>> >>> >> >>> test
>> >> >>> >>> >> >>> configuration.
>> >> >>> >>> >> >
>> >> >>> >>> >> >
>> >> >>> >>> >> > Should i keep login and server credentials into
>> >> >>> >>> >> > web/regression/test_config.json file and
>> >> >>> >>> >> > put respective node details into config.json file of
>> >> >>> >>> >> > respective
>> >> >>> >>> >> > node's
>> >> >>> >>> >> > tests
>> >> >>> >>> >> > directory?
>> >> >>> >>> >>
>> >> >>> >>> >> Not if you expect users to need to edit them - and if not,
>> >> >>> >>> >> why
>> >> >>> >>> >> are
>> >> >>> >>> >> the
>> >> >>> >>> >> values not just hard-coded?
>> >> >>> >>> >>
>> >> >>> >>> >> > e.g. for database node:
>> >> >>> >>> >> > I'll create config.json file into .../databases/tests/
>> >> >>> >>> >> > directory
>> >> >>> >>> >> > put database add and update credentials into config.json
>> >> >>> >>> >>
>> >> >>> >>> >> The key here is to make it simple for users.
>> >> >>> >>> >>
>> >> >>> >>> >> - To run the default tests, they should be able to copy/edit
>> >> >>> >>> >> a
>> >> >>> >>> >> simple
>> >> >>> >>> >> file, and just add database server details for the server to
>> >> >>> >>> >> run
>> >> >>> >>> >> against.
>> >> >>> >>> >>
>> >> >>> >>> >> - If we have configurable tests (because making them
>> >> >>> >>> >> configurable
>> >> >>> >>> >> adds
>> >> >>> >>> >> genuine value), then we can use an "advanced" config file to
>> >> >>> >>> >> allow
>> >> >>> >>> >> the
>> >> >>> >>> >> user to adjust settings as they want.
>> >> >>> >>> >>
>> >> >>> >>> >> In the simple case, the user should be able to run the tests
>> >> >>> >>> >> successfully within a minute or two from starting.
>> >> >>> >>> >>
>> >> >>> >>> >> In designing the layout for files etc, remember the
>> >> >>> >>> >> following:
>> >> >>> >>> >>
>> >> >>> >>> >> - Users should never edit a file that is in our source
>> >> >>> >>> >> control.
>> >> >>> >>> >> That's
>> >> >>> >>> >> why we have .in files that we expect them to copy.
>> >> >>> >>> >>
>> >> >>> >>> >> - Unless they're an advanced user, they shouldn't need to
>> >> >>> >>> >> copy
>> >> >>> >>> >> the
>> >> >>> >>> >> config file for advanced options. That means that the tests
>> >> >>> >>> >> should
>> >> >>> >>> >> have defaults that match what is in the template advanced
>> >> >>> >>> >> config
>> >> >>> >>> >> file
>> >> >>> >>> >> (or, the tests could read advanced.json.in if advanced.json
>> >> >>> >>> >> doesn't
>> >> >>> >>> >> exist, though that does seem a little icky). Of course,
>> >> >>> >>> >> those
>> >> >>> >>> >> are
>> >> >>> >>> >> example filenames, not necessarily what you may choose.
>> >> >>> >>> >>
>> >> >>> >>> >> --
>> >> >>> >>> >> Dave Page
>> >> >>> >>> >> Blog: http://pgsnake.blogspot.com
>> >> >>> >>> >> Twitter: @pgsnake
>> >> >>> >>> >>
>> >> >>> >>> >> EnterpriseDB UK: http://www.enterprisedb.com
>> >> >>> >>> >> The Enterprise PostgreSQL Company
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > --
>> >> >>> >>> > Best,
>> >> >>> >>> > Priyanka
>> >> >>> >>> >
>> >> >>> >>> > EnterpriseDB Corporation
>> >> >>> >>> > The Enterprise PostgreSQL Company
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> --
>> >> >>> >>> 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
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> Best,
>> >> >>> >> Priyanka
>> >> >>> >>
>> >> >>> >> EnterpriseDB Corporation
>> >> >>> >> The Enterprise PostgreSQL Company
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > --
>> >> >>> > Best,
>> >> >>> > Priyanka
>> >> >>> >
>> >> >>> > EnterpriseDB Corporation
>> >> >>> > The Enterprise PostgreSQL Company
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Dave Page
>> >> >>> Blog: http://pgsnake.blogspot.com
>> >> >>> Twitter: @pgsnake
>> >> >>>
>> >> >>> EnterpriseDB UK: http://www.enterprisedb.com
>> >> >>> The Enterprise PostgreSQL Company
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Best,
>> >> >> Priyanka
>> >> >>
>> >> >> EnterpriseDB Corporation
>> >> >> The Enterprise PostgreSQL Company
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Best,
>> >> > Priyanka
>> >> >
>> >> > EnterpriseDB Corporation
>> >> > The Enterprise PostgreSQL Company
>> >>
>> >>
>> >>
>> >> --
>> >> Dave Page
>> >> Blog: http://pgsnake.blogspot.com
>> >> Twitter: @pgsnake
>> >>
>> >> EnterpriseDB UK: http://www.enterprisedb.com
>> >> The Enterprise PostgreSQL Company
>> >
>> >
>> >
>> >
>> > --
>> > Best,
>> > Priyanka
>> >
>> > EnterpriseDB Corporation
>> > The Enterprise PostgreSQL Company
>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>
>
>
> --
> Best,
> Priyanka
>
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company



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

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



--
Best,
Priyanka

EnterpriseDB Corporation
The Enterprise PostgreSQL Company


pgadmin-hackers by date:

Previous
From: Priyanka Shendge
Date:
Subject: Re: pgAdmin IV API test cases patch
Next
From: Ashesh Vashi
Date:
Subject: Re: [Patch] Fix Unicode in errmsg