Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bMaHk-0007nQ-EW for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jul 2016 12:26:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bMaHj-0006YH-I6 for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jul 2016 12:26:03 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bMaHV-0006KQ-2o for pgadmin-hackers@postgresql.org; Mon, 11 Jul 2016 12:25:49 +0000 Received: from mail-qk0-x22b.google.com ([2607:f8b0:400d:c09::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bMaHQ-0002pZ-Ut for pgadmin-hackers@postgresql.org; Mon, 11 Jul 2016 12:25:47 +0000 Received: by mail-qk0-x22b.google.com with SMTP id 82so89388464qko.3 for ; Mon, 11 Jul 2016 05:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wa+zz5RdEq47olDc9MdYZykI90UvCE4VUOHF9S0Saps=; b=V66UTXrzcRItcznhyMpu8qKdsOZ5DgHoQd16fDyHET7hrivnU+SQyouJTHIp9WEDeH LG6F3SCfjnRpRIixkRAxVOAVRpSGlKup/Uuu+iZiMx69XlTVjAaLUEtrBq93eHZAFNGD OrZLjRCPw55uMLxXZjOj3AhX+pioMmkWmLavYzrtc8xtRfVjir8I4vUBohU6kCnAcr+p XF1WhQbNf51Frr/JEBs/ovrBwarhPJTZky0sIvyVQccdt+unOQrSribddF25WnL+e3N6 KT2ozXOPxgqHKPV7IHDp6gaRlDnwT7PqRxfDXzeJrdUlPorY6UTnu5PCGS7fabNMQJdE 7cHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wa+zz5RdEq47olDc9MdYZykI90UvCE4VUOHF9S0Saps=; b=QEIgBAB5p2xRvyBBC6On9EgHDgNNUlk+KzZjscUQsgNEU7P0U4g2LA7e3SV/2ZWh7i X3a50MnBaiB6v2yAlXIsj4DqY81hooqbINjzCjPkBElHSAtNCgNxOIgD+oK/gcIMwNfo Y9GHdo4v4zEKrwWb2Va8CYyD2e6Fl5fZR7hMUpQfZ2798Ibaj/5u/nLp0cOJo/AwuMPT nEieDJ1WSRRIL8rY6XYJxEZ/rscnfkndV32JJJI09C/WgcR8F+gPTCgZY3mjU1gFw/FJ MGTQVFrU+ZDqjbCnLl0E5Gy4DPUkpH02UPLPpb70lucg+AIL74Z4JJ/Rn9rhcL8919g8 +scQ== X-Gm-Message-State: ALyK8tKUdU9fPEKXiM6nREakGB604hvSyYySP6KRbHvmRmPjVRKxLa1DJZ7fxO7Hjb9D94hRI/eyiZgT5ql2KJ8y X-Received: by 10.55.212.147 with SMTP id s19mr25204674qks.64.1468239944006; Mon, 11 Jul 2016 05:25:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.51.174 with HTTP; Mon, 11 Jul 2016 05:25:24 -0700 (PDT) In-Reply-To: References: <1C830532-F2F0-4FBC-BD17-4428CE9AA53D@pgadmin.org> From: Priyanka Shendge Date: Mon, 11 Jul 2016 17:55:24 +0530 Message-ID: Subject: Re: pgAdmin IV API test cases patch To: Dave Page Cc: pgadmin-hackers , Kanchan Mohitey Content-Type: multipart/alternative; boundary=001a1149af4a4ed3ca05375b4079 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a1149af4a4ed3ca05375b4079 Content-Type: text/plain; charset=UTF-8 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 On 11 July 2016 at 17:18, Dave Page 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 > 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 wrote: > >> > >> Attached. > >> > >> On Tue, Jul 5, 2016 at 9:00 AM, Priyanka Shendge > >> 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 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 > >> >> 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 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 > >> >>> 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 > >> >>> > wrote: > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> On 27 June 2016 at 13:24, Dave Page wrote: > >> >>> >>> > >> >>> >>> On Sun, Jun 26, 2016 at 12:05 PM, Priyanka Shendge > >> >>> >>> wrote: > >> >>> >>> > > >> >>> >>> > > >> >>> >>> > On 24 June 2016 at 16:17, Dave Page > wrote: > >> >>> >>> >> > >> >>> >>> >> Hi > >> >>> >>> >> > >> >>> >>> >> On Thu, Jun 23, 2016 at 2:41 PM, Priyanka Shendge > >> >>> >>> >> wrote: > >> >>> >>> >> > > >> >>> >>> >> > > >> >>> >>> >> > On 15 June 2016 at 15:05, Priyanka Shendge > >> >>> >>> >> > wrote: > >> >>> >>> >> >> > >> >>> >>> >> >> Thanks a lot Dave. > >> >>> >>> >> >> > >> >>> >>> >> >> On 15 June 2016 at 14:09, Dave Page > >> >>> >>> >> >> wrote: > >> >>> >>> >> >>> > >> >>> >>> >> >>> Hi > >> >>> >>> >> >>> > >> >>> >>> >> >>> On Thu, Jun 9, 2016 at 1:37 PM, Priyanka Shendge > >> >>> >>> >> >>> 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 --001a1149af4a4ed3ca05375b4079 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, by mistake i copied incomplete query.=C2=A0 Th= ere is an OID present for added database.=C2=A0

SE= LECT
=C2=A0 =C2=A0 db.oid as did, db.datname, db.datallowconn,
=C2=A0 =C2=A0 pg_encoding_to_char(db.encoding) AS serverencoding,
=C2=A0 =C2=A0 has_database_privilege(db.oid, 'CREATE') as = cancreate, datlastsysoid
FROM
=C2=A0 =C2=A0 pg_database= db
WHERE db.oid =3D 158579


=
On 11 July 2016 at 17:18, Dave Page <dpage@pgad= min.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 O= ID
after the =3D

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 diffe= rent
> 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
>=C2=A0 =C2=A0 =C2=A0db.oid as did, db.datname, db.datallowconn,
>=C2=A0 =C2=A0 =C2=A0pg_encoding_to_char(db.encoding) AS serverencoding,=
>=C2=A0 =C2=A0 =C2=A0has_database_privilege(db.oid, 'CREATE') as= cancreate, datlastsysoid
> FROM
>=C2=A0 =C2=A0 =C2=A0pg_database db
> WHERE db.oid =3D
>
> Let me know if you have an extra system where I can reproduce the issu= e.
>
>
> 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 rep= roduce the
>> > failures.
>> > I have added debug statements to previous patch. Patch attach= ed.
>> > Could you please re-run the same and send me the logs and out= put?
>> >
>> > 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 Pytho= n 2.7 and
>> >> Python
>> >> 3.4.
>> >> Could you please provide me DEBUG logs and test data usin= g 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 at= tached.
>> >>>
>> >>> However, there are still issues:
>> >>>
>> >>> 1) The testsuite doesn't run to completion. See t= he 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 t= he 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 ".../pga= dmin4/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 separ= ate config files for
>> >>> > credentials and test data.
>> >>> >
>> >>> > PFA patch for same. Kindly, review and let me kn= ow 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, Priyan= ka Shendge
>> >>> >>> <priyanka.shendge@enterprisedb.com> wrote:
>> >>> >>> >
>> >>> >>> >
>> >>> >>> > On 24 June 2016 at 16:17, Dave Page= <dpage@pgadmin.org> wrote:<= br> >> >>> >>> >>
>> >>> >>> >> Hi
>> >>> >>> >>
>> >>> >>> >> On Thu, Jun 23, 2016 at 2:41 PM= , Priyanka Shendge
>> >>> >>> >> <priyanka.shendge@enterprisedb.com> wrote:<= br> >> >>> >>> >> >
>> >>> >>> >> >
>> >>> >>> >> > On 15 June 2016 at 15:05, = Priyanka Shendge
>> >>> >>> >> > <priyanka.shendge@enterprisedb.com> wr= ote:
>> >>> >>> >> >>
>> >>> >>> >> >> Thanks a lot Dave.
>> >>> >>> >> >>
>> >>> >>> >> >> On 15 June 2016 at 14:= 09, Dave Page <dpage@pgadmin.org>
>> >>> >>> >> >> wrote:
>> >>> >>> >> >>>
>> >>> >>> >> >>> Hi
>> >>> >>> >> >>>
>> >>> >>> >> >>> On Thu, Jun 9, 201= 6 at 1:37 PM, Priyanka Shendge
>> >>> >>> >> >>> <priyanka.shendge@enterprisedb.com> wrote:
>> >>> >>> >> >>> > Hi Dave,
>> >>> >>> >> >>> >
>> >>> >>> >> >>> > PFA updated p= atch. I have made changes suggested by you.
>> >>> >>> >> >>> >
>> >>> >>> >> >>> > Kindly, revie= w and let me know for more changes.
>> >>> >>> >> >>>
>> >>> >>> >> >>> OK, I got a bit fu= rther this time, but not there yet.
>> >>> >>> >> >>>
>> >>> >>> >> >>> 1) The patch overw= rote 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 tes= t_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=C2=A0 from >> >>> >>> > test_config.json while execution. >> >>> >>>
>> >>> >>> That doesn't answer my question - wh= y do we need separate
>> >>> >>> credentials
>> >>> >>> for each node?
>> >>> >>
>> >>> >>
>> >>> >> Sorry for typo, its test data not credential= s.
>> >>> >>
>> >>> >>>
>> >>> >>>
>> >>> >>> >> 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=C2=A0 taking care of each f= ield?
>> >>> >>>
>> >>> >>> You should have one set of credentials t= hat's used for the entire
>> >>> >>> test
>> >>> >>> run.
>> >>> >>
>> >>> >>
>> >>> >> Sure.=C2=A0 I'll separate the credential= s 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 c= hange 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 confi= guration info for "advanced users", let's
>> >>> >>> >> >>> put it
>> >>> >>> >> >>> in
>> >>> >>> >> >>> a different file t= o avoid confusing/scaring everyone else.
>> >>> >>> >> >>> Maybe
>> >>> >>> >> >>> split
>> >>> >>> >> >>> it into config.jso= n for the stuff the user needs to edit
>> >>> >>> >> >>> (config.json.in wo= uld go in git), and test_config.json for
>> >>> >>> >> >>> the
>> >>> >>> >> >>> test
>> >>> >>> >> >>> configuration.
>> >>> >>> >> >
>> >>> >>> >> >
>> >>> >>> >> > Should i keep login and se= rver credentials into
>> >>> >>> >> > web/regression/test_config= .json file and
>> >>> >>> >> > put respective node detail= s 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.jso= n file into .../databases/tests/
>> >>> >>> >> > directory
>> >>> >>> >> > put database add and updat= e credentials into config.json
>> >>> >>> >>
>> >>> >>> >> The key here is to make it simp= le for users.
>> >>> >>> >>
>> >>> >>> >> - To run the default tests, the= y should be able to copy/edit a
>> >>> >>> >> simple
>> >>> >>> >> file, and just add database ser= ver 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 sh= ould be able to run the tests
>> >>> >>> >> successfully within a minute or= two from starting.
>> >>> >>> >>
>> >>> >>> >> In designing the layout for fil= es etc, remember the following:
>> >>> >>> >>
>> >>> >>> >> - Users should never edit a fil= e that is in our source control.
>> >>> >>> >> That's
>> >>> >>> >> why we have .in files that we e= xpect them to copy.
>> >>> >>> >>
>> >>> >>> >> - Unless they're an advance= d user, they shouldn't need to copy
>> >>> >>> >> the
>> >>> >>> >> config file for advanced option= s. That means that the tests
>> >>> >>> >> should
>> >>> >>> >> have defaults that match what i= s in the template advanced
>> >>> >>> >> config
>> >>> >>> >> file
>> >>> >>> >> (or, the tests could read advance= d.json.in if advanced.json
>> >>> >>> >> doesn't
>> >>> >>> >> exist, though that does seem a = little icky). Of course, those
>> >>> >>> >> are
>> >>> >>> >> example filenames, not necessar= ily what you may choose.
>> >>> >>> >>
>> >>> >>> >> --
>> >>> >>> >> Dave Page
>> >>> >>> >> Blog: http://pgsnake.blogspot= .com
>> >>> >>> >> Twitter: @pgsnake
>> >>> >>> >>
>> >>> >>> >> EnterpriseDB UK: http://www.e= nterprisedb.com
>> >>> >>> >> The Enterprise PostgreSQL Compa= ny
>> >>> >>> >
>> >>> >>> >
>> >>> >>> >
>> >>> >>> >
>> >>> >>> > --
>> >>> >>> > Best,
>> >>> >>> > Priyanka
>> >>> >>> >
>> >>> >>> > EnterpriseDB Corporation
>> >>> >>> > The Enterprise PostgreSQL Company >> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>> Dave Page
>> >>> >>> Blog: http://pgsnake.blogspot.com<= br> >> >>> >>> Twitter: @pgsnake
>> >>> >>>
>> >>> >>> EnterpriseDB UK: http://www.enterprise= db.com
>> >>> >>> The Enterprise PostgreSQL Company
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>> Sent via pgadmin-hackers mailing list >> >>> >>> (pgadmin-hackers@postgresql.org)
>> >>> >>> To make changes to your subscription: >> >>> >>> http://www.post= gresql.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 Co= mpany
--001a1149af4a4ed3ca05375b4079--