Обсуждение: pgAdmin IV API test cases patch

Hi

On Sun, Jun 5, 2016 at 6:56 PM, Priyanka Shendge
<priyanka.shendge@enterprisedb.com> wrote:
> Hi,
>
> PFA patch for API test cases for tree nodes/modules. This patch does not
> include
> api tests for following modules:
>
> 1. Type
> 2. Table child nodes
> 3. FTS modules
>
> Kindly, review the same and let me know for any modification.

I took a very quick look at the patch and immediately saw a serious
problem I'm afraid - you cannot hard-code paths like this:

+            if os.path.isfile('/home/edb/Downloads/pgadmin4/web/regression/'
+                              'parent_id.pkl'):
+                exst_server_id = open('/home/edb/Downloads/pgadmin4/web'
+                                      '/regression/''parent_id.pkl', 'rb')

You need to dynamically generate such paths so this will work on any
machine. Look at line 19 of web/pgAdmin4.py to see how to get the
patch to the current file as an example.

Also; despite this not being part of the end-user interface, please
try to follow the standards for messages, e.g. instead of:

No event trigger(s) to update!!!

use

No event trigger(s) to update.

There is likely more to change of course, but please fix these issues first.

Thanks!

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

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

Ashesh - can you also look at the patch please (feel free to wait for
the update). I want more eyes on this.

Thanks.

On Wed, Jun 15, 2016 at 9:39 AM, 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.
>
> 2) The updated test_config.json file is huge. 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.
>
> 3) It fails on my machine, for what looks like a coding error
> initially, then a lot of issues where it can't find parent_id.pkl.
> I've attached the log.
>
> 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

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.

2) The updated test_config.json file is huge. 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.

3) It fails on my machine, for what looks like a coding error
initially, then a lot of issues where it can't find parent_id.pkl.
I've attached the log.

Thanks.

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

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

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? We should have just one set of credentials for
everything.

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

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  from
> test_config.json while execution.

That doesn't answer my question - why do we need separate credentials
for each node?

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

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

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

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

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

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

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?

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

On Tue, Jul 12, 2016 at 5:14 AM, Khushboo Vashi
<khushboo.vashi@enterprisedb.com> wrote:
>
>
> 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?

Not on my system, that I can think of.

If there was a connection error like that though, shouldn't we see a
message from libpq at least? If not, that implies that there are error
reporting issues to be fixed.


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

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

Hi

On Thu, Jul 14, 2016 at 12:50 PM, Priyanka Shendge
<priyanka.shendge@enterprisedb.com> wrote:
> Hi Dave,
>
> I have added more debug statements to older patch. New patch attached.
> Also, i removed database deletion test case from current patch so that we
> can analyse
> if database is added or not.

OK. One quick note - somewhere along the way,
test_advanced_config.json has been changed back to
test_advance_config.json. The first is correct - please include that
fix in the next patch.

The database is added - assuming you're referring to one randomly
named like bbb6cad or d602036?

> I have added few more debug statements to database add test case. After
> running the testsuite
> can you please confirm whether the database is created or not under server
> node?
>
> Could you please re-run the attached patch and send me the logs and output?

Sure - all the interesting info is here:

runTest (pgadmin.browser.tests.test_login.LoginTestCase)
This function checks login functionality. (TestCase for Checking
Invalid_Password) ... ok
runTest (pgadmin.browser.tests.test_login.LoginTestCase)
This function checks login functionality. (Empty_Password) ... ok
runTest (pgadmin.browser.tests.test_login.LoginTestCase)
This function checks login functionality. (Empty_Email) ... ok
runTest (pgadmin.browser.tests.test_login.LoginTestCase)
This function checks login functionality. (Empty_Creadentials) ... ok
runTest (pgadmin.browser.tests.test_login.LoginTestCase)
This function checks login functionality. (Invalid_Email) ... ok
runTest (pgadmin.browser.tests.test_login.LoginTestCase)
This function checks login functionality. (Invalid_Creadentials) ... ok
runTest (pgadmin.browser.tests.test_login.LoginTestCase)
This function checks login functionality. (Valid_Creadentials) ... ok
runTest (pgadmin.browser.server_groups.tests.test_sg_add.SgNodeTestCase)
This function will check available server groups. (Check Server Group
Node) ... ok
runTest (pgadmin.browser.tests.test_reset_password.ResetPasswordTestCase)
This function checks reset password functionality. (TestCase for
Validating Empty Email) ... ok
runTest (pgadmin.browser.tests.test_reset_password.ResetPasswordTestCase)
This function checks reset password functionality. (TestCase for
Validating Invalid_Email) ... ok
runTest (pgadmin.browser.tests.test_reset_password.ResetPasswordTestCase)
This function checks reset password functionality. (TestCase for
Validating Valid_Email) ... ok
runTest (pgadmin.browser.tests.test_change_password.ChangePasswordTestCase)
This function will check change password functionality. (TestCase for
Validating Incorrect_New_Password) ... ok
runTest (pgadmin.browser.tests.test_change_password.ChangePasswordTestCase)
This function will check change password functionality. (TestCase for
Validating New_Password_Less_Than_Min_Length) ... ok
runTest (pgadmin.browser.tests.test_change_password.ChangePasswordTestCase)
This function will check change password functionality. (TestCase for
Validating Empty_New_Password) ... ok
runTest (pgadmin.browser.tests.test_change_password.ChangePasswordTestCase)
This function will check change password functionality. (TestCase for
Validating Incorrect_Current_Password) ... ok
runTest (pgadmin.browser.tests.test_change_password.ChangePasswordTestCase)
This function will check change password functionality. (TestCase for
Changing Valid_Password) ... ok
runTest (pgadmin.browser.tests.test_change_password.ChangePasswordTestCase)
This function will check change password functionality.
(Reassigning_Password) ... ok
runTest (pgadmin.browser.server_groups.tests.test_sg_get.SgGetTestCase)
This function will check available server groups. (Check Server Group
Node) ... ok
runTest (pgadmin.browser.server_groups.servers.tests.test_server_add.ServersAddTestCase)
This function will add the server under default server group. (Default
Server Node url) ... ('\nServer id in server add', u'9')
ok
runTest (pgadmin.browser.server_groups.servers.tests.test_server_get.ServersGetTestCase)
This function will fetch the added servers to object browser. (Default
Server Node url) ... ok
runTest (pgadmin.browser.server_groups.servers.tests.test_server_put.ServerUpdateTestCase)
This function will update the server's comment field. (Default Server
Node url) ... 2016-07-15 13:29:39,946: INFO pgadmin: Connection
Request for server#9
FAIL
runTest (pgadmin.browser.server_groups.servers.databases.tests.test_db_add.DatabaseAddTestCase)
This function will add database under 1st server of tree node. (Check
Databases Node URL) ... 2016-07-15 13:29:39,956: INFO pgadmin:
Connection Request for server#9
FAIL
runTest (pgadmin.browser.server_groups.servers.databases.tests.test_db_get.DatabasesGetTestCase)
This function will fetch added database. (Check Databases Node URL) ...

('db id in get database from pickle:', 158619)
('Database Details From pickle: id in test nodes:', 158619)
2016-07-15 13:29:39,962: INFO pgadmin: Connection Request for server#9


('Server Connection Response After Database Addition in test nodes',
u'{"info": "", "errormsg": "Server not found.", "data": null,
"result": null, "success": 0}')
2016-07-15 13:29:39,969: ERROR pgadmin: Exception on
/browser/database/connect/1/9/158619 [POST]
Traceback (most recent call last):
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/views.py",
line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/utils.py", line
235, in dispatch_request
    return method(*args, **kwargs)
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/databases/__init__.py",
line 334, in connect
    conn = manager.connection(did=did, auto_reconnect=True)
AttributeError: 'NoneType' object has no attribute 'connection'


('Database Connection Response After Database Addition in test nodes',
u'<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">\n<title>500
Internal Server Error</title>\n<h1>Internal Server Error</h1>\n<p>The
server encountered an internal error and was unable to complete your
request.  Either the server is overloaded or there is an error in the
application.</p>\n')
ERROR
runTest (pgadmin.browser.server_groups.servers.databases.tests.test_db_put.DatabasesUpdateTestCase)
This function will update the comments field of database. (Check
Databases Node) ...

('db id in update database from pickle:', 158619)
('Database Details From pickle: id in test nodes:', 158619)
2016-07-15 13:29:39,976: INFO pgadmin: Connection Request for server#9


('Server Connection Response After Database Addition in test nodes',
u'{"info": "", "errormsg": "Server not found.", "data": null,
"result": null, "success": 0}')
2016-07-15 13:29:39,983: ERROR pgadmin: Exception on
/browser/database/connect/1/9/158619 [POST]
Traceback (most recent call last):
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/views.py",
line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/utils.py", line
235, in dispatch_request
    return method(*args, **kwargs)
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/databases/__init__.py",
line 334, in connect
    conn = manager.connection(did=did, auto_reconnect=True)
AttributeError: 'NoneType' object has no attribute 'connection'


('Database Connection Response After Database Addition in test nodes',
u'<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">\n<title>500
Internal Server Error</title>\n<h1>Internal Server Error</h1>\n<p>The
server encountered an internal error and was unable to complete your
request.  Either the server is overloaded or there is an error in the
application.</p>\n')
ERROR
runTest (pgadmin.browser.server_groups.servers.tests.test_server_delete.ServerDeleteTestCase)
This function will get all available servers under object browser
(Default Server Node url) ... ok
runTest (pgadmin.browser.tests.test_logout.LogoutTest)
This function checks the logout functionality. (Logging Out) ... ok

======================================================================
ERROR: runTest (pgadmin.browser.server_groups.servers.databases.tests.test_db_get.DatabasesGetTestCase)
This function will fetch added database. (Check Databases Node URL)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/databases/tests/test_db_get.py",
line 38, in runTest
    db_con = test_getnodes(node=self)
  File "/Users/dpage/git/pgadmin4/web/regression/test_nodes.py", line
48, in test_getnodes
    db_con = json.loads(con_response.data.decode())
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/__init__.py",
line 338, in loads
    return _default_decoder.decode(s)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py",
line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py",
line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

======================================================================
ERROR: runTest (pgadmin.browser.server_groups.servers.databases.tests.test_db_put.DatabasesUpdateTestCase)
This function will update the comments field of database. (Check Databases Node)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/databases/tests/test_db_put.py",
line 39, in runTest
    db_con = test_getnodes(node=self)
  File "/Users/dpage/git/pgadmin4/web/regression/test_nodes.py", line
48, in test_getnodes
    db_con = json.loads(con_response.data.decode())
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/__init__.py",
line 338, in loads
    return _default_decoder.decode(s)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py",
line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/decoder.py",
line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

======================================================================
FAIL: runTest (pgadmin.browser.server_groups.servers.tests.test_server_put.ServerUpdateTestCase)
This function will update the server's comment field. (Default Server Node url)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/tests/test_server_put.py",
line 64, in runTest
    self.assertTrue(respdata['success'], 1)
AssertionError: 1

======================================================================
FAIL: runTest (pgadmin.browser.server_groups.servers.databases.tests.test_db_add.DatabaseAddTestCase)
This function will add database under 1st server of tree node. (Check
Databases Node URL)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/databases/tests/test_db_add.py",
line 47, in runTest
    self.assertEquals(response.status_code, 200)
AssertionError: 400 != 200

----------------------------------------------------------------------
Ran 26 tests in 12.312s

FAILED (failures=2, errors=2)
('Please check output in file: logger.log placed at',
'/Users/dpage/git/pgadmin4/web/regression')
Traceback (most recent call last):
  File "regression/testsuite.py", line 113, in <module>
    os.remove("parent_id.pkl")
OSError: [Errno 2] No such file or directory: 'parent_id.pkl'
(pgadmin4)piranha:web dpage$

The output log doesn't seem to contain anything more useful.

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

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