Re: [pgAdmin4] RESQL tests for Column & Type nodes

[navnath gadakh]

Hi Murtuza,

 Patch looks good to me.

Thanks!

On Wed, Apr 29, 2020 at 2:38 PM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> I will review and test it.
>
> On Wed, Apr 29, 2020 at 2:27 PM Murtuza Zabuawala <
> murtuza.zabuaw...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> PFA patch to add RESQL tests for Column and Type nodes.
>>
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin4] RESQL tests for Column & Type nodes

[navnath gadakh]

I will review and test it.

On Wed, Apr 29, 2020 at 2:27 PM Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Hi,
>
> PFA patch to add RESQL tests for Column and Type nodes.
>
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>

-- 
Regards,
Navnath Gadakh

Re: [pgAdmin4][Patch] - RM 5422 - Synonym Dependencies tab shows incorrect data

[navnath gadakh]

Hi Khushboo,

 Patch looks good to me except there are no API test cases written for
dependents and dependencies.

Thanks!

On Wed, Apr 29, 2020 at 10:40 AM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> Hi ,
>
>  I'm reviewing this task.
>
> On Wed, Apr 29, 2020 at 9:36 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Please find the attached patch to fix the RM 5422 - Synonym Dependencies
>> tab shows incorrect data.
>>
>> Thanks,
>> Khushboo
>>
>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin4][Patch] - RM 5422 - Synonym Dependencies tab shows incorrect data

[navnath gadakh]

Hi ,

 I'm reviewing this task.

On Wed, Apr 29, 2020 at 9:36 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> Please find the attached patch to fix the RM 5422 - Synonym Dependencies
> tab shows incorrect data.
>
> Thanks,
> Khushboo
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM4504] Make like options disable if Relation is not selected.

[navnath gadakh]

Hi Pradip,
  Patch looks good to me except one minor issue -
Create a table without selecting any relation then try to update table like
options switch buttons are still enabled.



On Fri, Apr 24, 2020 at 3:04 PM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> Hi,
>   I will be reviewing this RM.
>
> On Fri, Apr 24, 2020 at 1:48 PM Pradip Parkale <
> pradip.park...@enterprisedb.com> wrote:
>
>> Hi Hackers,
>>
>> Attached is a patch to make like options disable if Relation is not
>> selected while creating a table.
>>
>> Please review.
>>
>> --
>> Thanks & Regards,
>> Pradip Parkale
>> QMG, EnterpriseDB Corporation
>>
>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM4504] Make like options disable if Relation is not selected.

[navnath gadakh]

Hi,
  I will be reviewing this RM.

On Fri, Apr 24, 2020 at 1:48 PM Pradip Parkale <
pradip.park...@enterprisedb.com> wrote:

> Hi Hackers,
>
> Attached is a patch to make like options disable if Relation is not
> selected while creating a table.
>
> Please review.
>
> --
> Thanks & Regards,
> Pradip Parkale
> QMG, EnterpriseDB Corporation
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM5043] Column names not in creation order during - refresh via context menu required to resort them properly

[navnath gadakh]

Hello,

 Patch looks good to me. Newly created columns sorted according to their
creation order without context refresh.

Thanks!

On Thu, Apr 23, 2020 at 10:13 AM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> Hi,
>
>  I'm reviewing this patch.
>
> On Wed, Apr 22, 2020 at 6:54 PM Satish V 
> wrote:
>
>>
>> Hi Hackers,
>>
>> In the attached patch, newly created columns in a table are sorted
>> according to their creation order rather than the alphanumerical order.
>> Previously this was not happening without context refresh.
>>
>>
>>
>> Please review.
>>
>> Thanks
>> Sathish V
>>
>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM5043] Column names not in creation order during - refresh via context menu required to resort them properly

[navnath gadakh]

Hi,

 I'm reviewing this patch.

On Wed, Apr 22, 2020 at 6:54 PM Satish V  wrote:

>
> Hi Hackers,
>
> In the attached patch, newly created columns in a table are sorted
> according to their creation order rather than the alphanumerical order.
> Previously this was not happening without context refresh.
>
>
>
> Please review.
>
> Thanks
> Sathish V
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM5352] : Rightmost & Bottom tooltip crop issues in Explain Query Plan

[navnath gadakh]

Please commit the second patch as there is an issue with first one for the
zoom factor.

On Wed, Apr 22, 2020 at 4:50 PM Akshay Joshi 
wrote:

> Patch is committed :). Not pushed
>
> On Wed, 22 Apr, 2020, 16:46 navnath gadakh, <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hi,
>>
>>  I'm reviewing this patch.
>>
>> On Wed, Apr 22, 2020 at 3:09 PM Yogesh Jain 
>> wrote:
>>
>>> Hi Hackers,
>>>
>>> Here is an updated patch which solves the problem of more large query
>>> which deals fine with zoom factor as well .
>>>
>>> FYI: During testing it was found that the previous patch was only
>>> working for mid sized query and not more large complex query due to zoom
>>> factor issue.
>>>
>>> Please review the new patch.
>>> PFA.
>>>
>>> On Tue, Apr 21, 2020 at 1:32 PM Akshay Joshi <
>>> akshay.jo...@enterprisedb.com> wrote:
>>>
>>>> Thanks, patch applied.
>>>>
>>>> On Mon, Apr 20, 2020 at 8:05 PM Yogesh Jain <
>>>> yogesh.j...@enterprisedb.com> wrote:
>>>>
>>>>> Hi Hackers,
>>>>>
>>>>> Attached is the patch to fix the rightmost & bottom tooltip crop
>>>>> issues in the explain query plan.
>>>>>
>>>>> FYI : While explaining a large query if we hover the rightmost
>>>>> or bottom icon the tooltip is cropped & partially visible, which is fixed
>>>>> in this patch.
>>>>>
>>>>> Please review.
>>>>> PFA.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Yogesh Jain
>>>>> 8982696654
>>>>>
>>>>
>>>>
>>>> --
>>>> *Thanks & Regards*
>>>> *Akshay Joshi*
>>>>
>>>> *Sr. Software Architect*
>>>> *EnterpriseDB Software India Private Limited*
>>>> *Mobile: +91 976-788-8246*
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Yogesh Jain
>>> 8982696654
>>>
>>
>>
>> --
>> Regards,
>> Navnath Gadakh
>>
>

-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM5352] : Rightmost & Bottom tooltip crop issues in Explain Query Plan

[navnath gadakh]

Hi,

 I'm reviewing this patch.

On Wed, Apr 22, 2020 at 3:09 PM Yogesh Jain 
wrote:

> Hi Hackers,
>
> Here is an updated patch which solves the problem of more large query
> which deals fine with zoom factor as well .
>
> FYI: During testing it was found that the previous patch was only working
> for mid sized query and not more large complex query due to zoom factor
> issue.
>
> Please review the new patch.
> PFA.
>
> On Tue, Apr 21, 2020 at 1:32 PM Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Thanks, patch applied.
>>
>> On Mon, Apr 20, 2020 at 8:05 PM Yogesh Jain 
>> wrote:
>>
>>> Hi Hackers,
>>>
>>> Attached is the patch to fix the rightmost & bottom tooltip crop issues
>>> in the explain query plan.
>>>
>>> FYI : While explaining a large query if we hover the rightmost or bottom
>>> icon the tooltip is cropped & partially visible, which is fixed in this
>>> patch.
>>>
>>> Please review.
>>> PFA.
>>>
>>> --
>>> Regards,
>>> Yogesh Jain
>>> 8982696654
>>>
>>
>>
>> --
>> *Thanks & Regards*
>> *Akshay Joshi*
>>
>> *Sr. Software Architect*
>> *EnterpriseDB Software India Private Limited*
>> *Mobile: +91 976-788-8246*
>>
>
>
> --
> Regards,
> Yogesh Jain
> 8982696654
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin4][Patch] - RM 3900 - Delete/Drop option is disabled for the constraints

[navnath gadakh]

Patch looks good to me.

On Wed, Apr 22, 2020 at 1:54 PM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> Hello,
>
>  I'm reviewing this RM.
>
> On Wed, Apr 22, 2020 at 10:55 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Please find the attached patch to fix the RM #3900 - Delete/Drop option
>> is disabled for the constraints.
>>
>> - Implemented multiple drop/delete functionality for the Table
>> constraints.
>>
>> Thanks,
>> Khushboo
>>
>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin4][Patch] - RM 3900 - Delete/Drop option is disabled for the constraints

[navnath gadakh]

Hello,

 I'm reviewing this RM.

On Wed, Apr 22, 2020 at 10:55 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> Please find the attached patch to fix the RM #3900 - Delete/Drop option
> is disabled for the constraints.
>
> - Implemented multiple drop/delete functionality for the Table constraints.
>
> Thanks,
> Khushboo
>


-- 
Regards,
Navnath Gadakh

Exclude RESQL test cases

[navnath gadakh]

Hello Hackers,

  Please review the small patch to exclude RESQL test cases.  resql
param is added to --exclude.

Thanks!

-- 
Regards,
Navnath Gadakh


exclude_resql_tests_v1.patch
Description: Binary data

Re: [pgAdmin][RM5157] Default sort order at start in view table data by primary key by default

[navnath gadakh]

Hello Hackers,
 It's related to applying data sorting on table data by primary key.
With the existing implementation, we can view the table's data using 4
options with the different orders by default
1 - All Rows (No order)
2 - First 100 rows (ASC order)
3 - Last 100 rows (DESC order)
4 - Filtered rows (No order)

In the https://redmine.postgresql.org/issues/5157  it's not clearly
mentioned on which option to apply sorting by PK?  I'm assuming that should
be on ALL Rows option.

Please suggest.

Thanks!


On Tue, Apr 21, 2020 at 10:12 AM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> Hi Khushboo,
> Please hold this patch for review I'm still optimizing the code in the
> patch.
>
>
> On Mon, Apr 20, 2020 at 9:16 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hi Khushboo,
>>I have modified the code as per review comments. Please review the
>> attached patch file.
>>
>> Thanks!
>>
>> On Mon, Apr 20, 2020 at 10:56 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi Navnath,
>>>
>>> Review comments:
>>>
>>> 1. If we have multiple Primary keys, then we should include all the keys
>>> into the Order by clause.
>>> 2. In the Preferences dialog, please put this option  in the Query Tool
>>> > Options instead of Result Grid and also change the Label.
>>> 3. Please optimize the code, as I can see objectname.sql file is being
>>> used in else condition also, which is not required. Based on the parameter
>>> setting, Just one call of that sql is enough.
>>>
>>> Thanks,
>>> Khushboo
>>>
>>>
>>> On Fri, Apr 17, 2020 at 6:43 PM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
>>>> Hello Hackers,
>>>>
>>>>  Please find the modified patch with an option in Preferences for data
>>>> sorting by the primary key. Also, the previous  patch was not working with
>>>> table has no primary key.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 16, 2020 at 5:01 PM Dave Page 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 16, 2020 at 12:08 PM navnath gadakh <
>>>>> navnath.gad...@enterprisedb.com> wrote:
>>>>>
>>>>>> Hi Dave/Team,
>>>>>>   This patch is related to the default sort order for the
>>>>>> view table data. In pgAdminIII default ordering is by primary key and 
>>>>>> this
>>>>>> is not working in pgAdminIV.
>>>>>> I have attached the patch with the back end code.
>>>>>>
>>>>>> Please review it.
>>>>>>
>>>>>> *Question*: There is one suggestion on
>>>>>> https://redmine.postgresql.org/issues/5157 about to put a checkbox
>>>>>> in the configuration for this behavior.
>>>>>>   Do I need to implement that really? I yes, Is
>>>>>> preferences a good place for that? / Suggestions?
>>>>>>
>>>>>
>>>>> I think we should make this optional, and yes, Preferences is a good
>>>>> place. The reason is that sorting data is not without cost - at the very
>>>>> least it will require use of an index to access what may be the whole 
>>>>> table.
>>>>>
>>>>> --
>>>>> Dave Page
>>>>> VP & Chief Architect, Database Infrastructure
>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>> Blog: http://pgsnake.blogspot.com
>>>>> Twitter: @pgsnake
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Navnath Gadakh
>>>>
>>>
>>
>> --
>> Regards,
>> Navnath Gadakh
>>
>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM5157] Default sort order at start in view table data by primary key by default

[navnath gadakh]

Hi Khushboo,
Please hold this patch for review I'm still optimizing the code in the
patch.


On Mon, Apr 20, 2020 at 9:16 PM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> Hi Khushboo,
>I have modified the code as per review comments. Please review the
> attached patch file.
>
> Thanks!
>
> On Mon, Apr 20, 2020 at 10:56 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi Navnath,
>>
>> Review comments:
>>
>> 1. If we have multiple Primary keys, then we should include all the keys
>> into the Order by clause.
>> 2. In the Preferences dialog, please put this option  in the Query Tool >
>> Options instead of Result Grid and also change the Label.
>> 3. Please optimize the code, as I can see objectname.sql file is being
>> used in else condition also, which is not required. Based on the parameter
>> setting, Just one call of that sql is enough.
>>
>> Thanks,
>> Khushboo
>>
>>
>> On Fri, Apr 17, 2020 at 6:43 PM navnath gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> Hello Hackers,
>>>
>>>  Please find the modified patch with an option in Preferences for data
>>> sorting by the primary key. Also, the previous  patch was not working with
>>> table has no primary key.
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>> On Thu, Apr 16, 2020 at 5:01 PM Dave Page 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 16, 2020 at 12:08 PM navnath gadakh <
>>>> navnath.gad...@enterprisedb.com> wrote:
>>>>
>>>>> Hi Dave/Team,
>>>>>   This patch is related to the default sort order for the view
>>>>> table data. In pgAdminIII default ordering is by primary key and this is
>>>>> not working in pgAdminIV.
>>>>> I have attached the patch with the back end code.
>>>>>
>>>>> Please review it.
>>>>>
>>>>> *Question*: There is one suggestion on
>>>>> https://redmine.postgresql.org/issues/5157 about to put a checkbox in
>>>>> the configuration for this behavior.
>>>>>   Do I need to implement that really? I yes, Is
>>>>> preferences a good place for that? / Suggestions?
>>>>>
>>>>
>>>> I think we should make this optional, and yes, Preferences is a good
>>>> place. The reason is that sorting data is not without cost - at the very
>>>> least it will require use of an index to access what may be the whole 
>>>> table.
>>>>
>>>> --
>>>> Dave Page
>>>> VP & Chief Architect, Database Infrastructure
>>>> EnterpriseDB: http://www.enterprisedb.com
>>>> The Enterprise PostgreSQL Company
>>>>
>>>> Blog: http://pgsnake.blogspot.com
>>>> Twitter: @pgsnake
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Navnath Gadakh
>>>
>>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM5157] Default sort order at start in view table data by primary key by default

[navnath gadakh]

Hi Khushboo,
   I have modified the code as per review comments. Please review the
attached patch file.

Thanks!

On Mon, Apr 20, 2020 at 10:56 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi Navnath,
>
> Review comments:
>
> 1. If we have multiple Primary keys, then we should include all the keys
> into the Order by clause.
> 2. In the Preferences dialog, please put this option  in the Query Tool >
> Options instead of Result Grid and also change the Label.
> 3. Please optimize the code, as I can see objectname.sql file is being
> used in else condition also, which is not required. Based on the parameter
> setting, Just one call of that sql is enough.
>
> Thanks,
> Khushboo
>
>
> On Fri, Apr 17, 2020 at 6:43 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hello Hackers,
>>
>>  Please find the modified patch with an option in Preferences for data
>> sorting by the primary key. Also, the previous  patch was not working with
>> table has no primary key.
>>
>> Thanks!
>>
>>
>>
>>
>> On Thu, Apr 16, 2020 at 5:01 PM Dave Page 
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 16, 2020 at 12:08 PM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
>>>> Hi Dave/Team,
>>>>   This patch is related to the default sort order for the view
>>>> table data. In pgAdminIII default ordering is by primary key and this is
>>>> not working in pgAdminIV.
>>>> I have attached the patch with the back end code.
>>>>
>>>> Please review it.
>>>>
>>>> *Question*: There is one suggestion on
>>>> https://redmine.postgresql.org/issues/5157 about to put a checkbox in
>>>> the configuration for this behavior.
>>>>   Do I need to implement that really? I yes, Is
>>>> preferences a good place for that? / Suggestions?
>>>>
>>>
>>> I think we should make this optional, and yes, Preferences is a good
>>> place. The reason is that sorting data is not without cost - at the very
>>> least it will require use of an index to access what may be the whole table.
>>>
>>> --
>>> Dave Page
>>> VP & Chief Architect, Database Infrastructure
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>
>>
>> --
>> Regards,
>> Navnath Gadakh
>>
>

-- 
Regards,
Navnath Gadakh


RM-5157_v3.patch
Description: Binary data

Re: [pgAdmin][RM5157] Default sort order at start in view table data by primary key by default

[navnath gadakh]

Hello Hackers,

 Please find the modified patch with an option in Preferences for data
sorting by the primary key. Also, the previous  patch was not working with
table has no primary key.

Thanks!




On Thu, Apr 16, 2020 at 5:01 PM Dave Page 
wrote:

>
>
> On Thu, Apr 16, 2020 at 12:08 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hi Dave/Team,
>>   This patch is related to the default sort order for the view
>> table data. In pgAdminIII default ordering is by primary key and this is
>> not working in pgAdminIV.
>> I have attached the patch with the back end code.
>>
>> Please review it.
>>
>> *Question*: There is one suggestion on
>> https://redmine.postgresql.org/issues/5157 about to put a checkbox in
>> the configuration for this behavior.
>>   Do I need to implement that really? I yes, Is
>> preferences a good place for that? / Suggestions?
>>
>
> I think we should make this optional, and yes, Preferences is a good
> place. The reason is that sorting data is not without cost - at the very
> least it will require use of an index to access what may be the whole table.
>
> --
> Dave Page
> VP & Chief Architect, Database Infrastructure
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>


-- 
Regards,
Navnath Gadakh


RM-5157_v2.patch
Description: Binary data

[pgAdmin][RM5157] Default sort order at start in view table data by primary key by default

[navnath gadakh]

Hi Dave/Team,
  This patch is related to the default sort order for the view
table data. In pgAdminIII default ordering is by primary key and this is
not working in pgAdminIV.
I have attached the patch with the back end code.

Please review it.

*Question*: There is one suggestion on
https://redmine.postgresql.org/issues/5157 about to put a checkbox in the
configuration for this behavior.
  Do I need to implement that really? I yes, Is preferences
a good place for that? / Suggestions?

Thanks!

-- 
Regards,
Navnath Gadakh


RM-5157_v1.patch
Description: Binary data

Re: [pgAdmin 4 - Housekeeping #5255] Implement Selenium Grid using multi-threading & solenoid using current test framework

[navnath gadakh]

Hi,
I think I am not the right person to review this patch now as I already
reviewed this code offline in the last week. I know the approached Yogesh
has followed, also given some review comments on it.
Someone else please review it.

Thanks!

On Mon, Apr 13, 2020 at 2:49 PM Akshay Joshi 
wrote:

> Hi Navnath
>
> Can you please review it?
>
> On Mon, Apr 13, 2020 at 2:40 PM Yogesh Mahajan <
> yogesh.maha...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Please find the attached patch for running *features tests* using
>> solenoid(selenium grid + docker).
>> KIndly review.
>> To sun feature tests in parallel, required prerequisites can be checked
>> in '~/web/regression/README' file.
>> Also detailed instructions are added in the same file.
>> After applying the patch, any existing process for execution of
>> API/Features tests remains the same.
>>
>>
>> Thanks,
>> Yogesh Mahajan
>> QA - Team
>> EnterpriseDB Corporation
>>
>> Phone: +91-9741705709
>>
>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
>
> *Sr. Software Architect*
> *EnterpriseDB Software India Private Limited*
> *Mobile: +91 976-788-8246*
>


-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[navnath gadakh]

@Dave Page   @Akshay Joshi
 your input please?

On Wed, Apr 15, 2020 at 3:13 PM Neel Patel 
wrote:

> Hi,
>
> I think we should remove the type cast from query during update and
> whatever error is thrown should be shown to UI as per scenario 3.
>
> Thanks,
> Neel Patel
>
> On Wed, Apr 15, 2020 at 3:06 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Wed, Apr 15, 2020 at 2:48 PM navnath gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> Hello Hackers,
>>>
>>>
>>> On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
>>>> Hi Navnath,
>>>>
>>>> You have compared the column's internal size with the length of the
>>>> value given by the user.
>>>> For example, column having integer would have internal size 4 and if I
>>>> give the value 12121 which is the correct input for the field will fail
>>>> here because as per your logic column internal size (4) < len(value) (5).
>>>>
>>>> I think this implementation is not correct here.
>>>>
>>> Yes, my implementations might be wrong.
>>>
>>> Below are some important findings on the parameterised query(as we are
>>> using Jinja templates for building SQL queries).
>>> Here I have created a table 'account' with some records in it.
>>> CREATE TABLE public.account
>>> (
>>> user_id integer NOT NULL,
>>> username character varying(5)
>>> )
>>>
>>> psycopg2 throws a proper error if I pass username value greater than the
>>> length of the data type(5)
>>> Now, I want to pass username value greater than data type length (5)
>>>
>>> Scenario 1:  Query with data type and length
>>>
>>> import psycopg2
>>> try:
>>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>>> cur = conn.cursor()
>>> cur.execute("UPDATE public.account SET username = 
>>> %(username)s::character varying(5) WHERE user_id = 1;", {"username": 
>>> "username-test-123"})
>>> cur.execute("COMMIT;")
>>> except Exception as e:
>>> print('Exception : {0}'.format(e))
>>>
>>> *Output:*
>>>
>>> It will save the record with 5 char data without any error.
>>>
>>> *psql output:*
>>>
>>> postgres=# select * from public.account;
>>>  user_id | username
>>> -+--
>>>1 | usern
>>> (1 row)
>>>
>>> Scenario 2:  Query with only data type
>>>
>>> import psycopg2
>>> try:
>>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>>> cur = conn.cursor()
>>> cur.execute("UPDATE public.account SET username = 
>>> %(username)s::character varying WHERE user_id = 1;", {"username": 
>>> "username-test-123"})
>>> cur.execute("COMMIT;")
>>> except Exception as e:
>>> print('Exception : {0}'.format(e))
>>>
>>> *Output:*
>>>
>>> Exception : value too long for type character varying(5)
>>>
>>> data will not save in the table.
>>>
>>> We can consider scenario 2  as it will throw the valid exception and
>> also typecast the value in the proper format.
>>
>>> Scenario 3:  Query without data type
>>>
>>> import psycopg2
>>> try:
>>> conn = psycopg2.connect("dbname='postgres' user='postgres' 
>>> host='XXX.XXX.XXX.XXX' password='test' port=5432")
>>> cur = conn.cursor()
>>> cur.execute("UPDATE public.account SET username = %(username)s WHERE 
>>> user_id = 1;", {"username": "username-test-123"})
>>> cur.execute("COMMIT;")
>>> except Exception as e:
>>> print('Exception : {0}'.format(e))
>>>
>>> *Output:*
>>>
>>> Exception : value too long for type character varying(5)
>>>
>>> again data will not save in the table.
>>>
>>> These are some different behaviours with psycopg2. So to complete this 
>>> patch which apporach should I follow? or any new approach is also welcome.
>>>
>>> Thanks!
>>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> Khushboo
>>>>
>>>>
>>>>
>>>> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
>>>> navnath.gad...@enterprisedb.com> wrote:
>>>>
>>>>> Hello Hackers,
>>>>> Please find the attached patch for below fixes:
>>>>>
>>>>> - Added validation for table row data that should not be larger
>>>>> than the field size.
>>>>> - Rearrange the existing functions to add validation.
>>>>> - Added test cases.
>>>>>
>>>>> Regards,
>>>>> Navnath Gadakh
>>>>>
>>>>>
>>>
>>> --
>>> Regards,
>>> Navnath Gadakh
>>>
>>

-- 
Regards,
Navnath Gadakh

Re: [pgAdmin][RM5210] pgAdmin4 silently truncates text larger than underlying field size

[navnath gadakh]

Hello Hackers,


On Tue, Apr 14, 2020 at 5:14 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi Navnath,
>
> You have compared the column's internal size with the length of the value
> given by the user.
> For example, column having integer would have internal size 4 and if I
> give the value 12121 which is the correct input for the field will fail
> here because as per your logic column internal size (4) < len(value) (5).
>
> I think this implementation is not correct here.
>
Yes, my implementations might be wrong.

Below are some important findings on the parameterised query(as we are
using Jinja templates for building SQL queries).
Here I have created a table 'account' with some records in it.
CREATE TABLE public.account
(
user_id integer NOT NULL,
username character varying(5)
)

psycopg2 throws a proper error if I pass username value greater than the
length of the data type(5)
Now, I want to pass username value greater than data type length (5)

Scenario 1:  Query with data type and length

import psycopg2
try:
conn = psycopg2.connect("dbname='postgres' user='postgres'
host='XXX.XXX.XXX.XXX' password='test' port=5432")
cur = conn.cursor()
cur.execute("UPDATE public.account SET username =
%(username)s::character varying(5) WHERE user_id = 1;", {"username":
"username-test-123"})
cur.execute("COMMIT;")
except Exception as e:
print('Exception : {0}'.format(e))

*Output:*

It will save the record with 5 char data without any error.

*psql output:*

postgres=# select * from public.account;
 user_id | username
-+--
   1 | usern
(1 row)

Scenario 2:  Query with only data type

import psycopg2
try:
conn = psycopg2.connect("dbname='postgres' user='postgres'
host='XXX.XXX.XXX.XXX' password='test' port=5432")
cur = conn.cursor()
cur.execute("UPDATE public.account SET username =
%(username)s::character varying WHERE user_id = 1;", {"username":
"username-test-123"})
cur.execute("COMMIT;")
except Exception as e:
print('Exception : {0}'.format(e))

*Output:*

Exception : value too long for type character varying(5)

data will not save in the table.

Scenario 3:  Query without data type

import psycopg2
try:
conn = psycopg2.connect("dbname='postgres' user='postgres'
host='XXX.XXX.XXX.XXX' password='test' port=5432")
cur = conn.cursor()
cur.execute("UPDATE public.account SET username = %(username)s
WHERE user_id = 1;", {"username": "username-test-123"})
cur.execute("COMMIT;")
except Exception as e:
print('Exception : {0}'.format(e))

*Output:*

Exception : value too long for type character varying(5)

again data will not save in the table.

These are some different behaviours with psycopg2. So to complete this
patch which apporach should I follow? or any new approach is also
welcome.

Thanks!



>
> Thanks,
> Khushboo
>
>
>
> On Tue, Apr 14, 2020 at 4:33 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hello Hackers,
>> Please find the attached patch for below fixes:
>>
>> - Added validation for table row data that should not be larger than the
>> field size.
>> - Rearrange the existing functions to add validation.
>> - Added test cases.
>>
>> Regards,
>> Navnath Gadakh
>>
>>

-- 
Regards,
Navnath Gadakh

Re: [pgAdmin4][Patch] - RM 2186 - Support external authentication sources [LDAP]

[navnath gadakh]

Hi Khushboo,
   I think there is no use of

+if app is not None:
+AuthSourceRegistry.load_auth_sources()
+

in get_auth_sources() function.


On Tue, Mar 17, 2020 at 2:25 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> Please find the attached patch to support LDAP Authentication in Server
> mode.
> To test the patch, config_auth.py needs to be configured for LDAP
> configurations. The config settings are explained in this file in detail.
> After configuring the parameters, start the pgadmin server in Server mode
> and connect with LDAP server with the valid user via login page.
>
> I have tested this patch with ldap and ldap + ssl/tls. With the TLS, I
> have used the default config of ldap3 without certificates.
>
> @Dave, can you please review this patch, as you have a better
> understanding of LDAP and you can easily pointed out if I have missed
> anything.
>
> Note: For the document update I will create the task and assign to Nidhi
> for the same.
>
> Thanks,
> Khushboo
>


-- 
*-- Navnath*

[pgAdmin][RM5048] : code coverage tool

[navnath gadakh]

Hi Team,
  Please find the attached patch to calculate code coverage if pgadmin
code(python tests).
I have extended the existing testsuite to enable coverage. I have used
python's coverage module.

*Some useful commands: *

before running the commands make sure you create .coveragerc file under
/regression directory(details mentioned in README)
Run coverage

With all modules
run 'python runtests.py --coverage --exclude feature_tests'
With specific module
run 'python runtests.py --pkg
browser.server_groups.servers.tests --coverage'

Thanks!
-- 
*Regards,*
*Navnath Gadakh*


pgadmin_code_coverage_v1.patch
Description: Binary data

Re: RE-SQL tests patch for packages node

[navnath gadakh]

Please check now.

On Tue, Sep 3, 2019 at 5:07 PM Akshay Joshi 
wrote:

> Hi Navnath
>
> You forgot to add "create_package_with_all_options_msql.sql" and
> "alter_package_headers_and_comment_msql.sql" file in your patch. Please
> send the updated patch.
>
> On Tue, Sep 3, 2019 at 1:36 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Please find the modified patch.
>>
>> On Mon, Sep 2, 2019 at 5:43 PM Akshay Joshi <
>> akshay.jo...@enterprisedb.com> wrote:
>>
>>> Hi Navnath
>>>
>>> Following are the review comments:
>>>
>>>- GRANT statement is not visible in RE-SQL for create and alter
>>>both. (May be bug in Packages please fix that too)
>>>
>>> Done.
>>
>>>
>>>- Delete packages is missing in json file.
>>>
>>> Done.
>>
>>>
>>>- Add test cases to revoke privileges(delete all the privileges).
>>>Check Languages node for reference.
>>>
>>> Done.
>>
>>>
>>> On Mon, Sep 2, 2019 at 5:03 PM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
>>>> Hi Dave,
>>>>  Please find the patch for M-SQL test cases for *Packages*
>>>> module.
>>>>
>>>> Thanks!
>>>>
>>>> On Fri, Jul 12, 2019 at 4:02 PM Dave Page 
>>>> wrote:
>>>>
>>>>> Thanks, applied.
>>>>>
>>>>> On Fri, Jul 12, 2019 at 11:24 AM navnath gadakh <
>>>>> navnath.gad...@enterprisedb.com> wrote:
>>>>>
>>>>>> Hi Dave,
>>>>>>
>>>>>>  Please find the modified patch for packages as test cases were
>>>>>> failing on some servers.
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 11, 2019 at 1:53 PM Dave Page 
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks, applied.
>>>>>>>
>>>>>>> On Thu, Jul 11, 2019 at 8:07 AM Akshay Joshi <
>>>>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>>>>
>>>>>>>> Hi Navnath
>>>>>>>>
>>>>>>>> I have tested the patch and it is not working for EPAS 9.4, 9.5 and
>>>>>>>> 9.6. Attached is the modified patch which fix the issue.
>>>>>>>> Please work on child node (functions, procedure and variables) of
>>>>>>>> Packages on top of modified patch.
>>>>>>>>
>>>>>>>> On Wed, Jul 10, 2019 at 8:25 PM navnath gadakh <
>>>>>>>> navnath.gad...@enterprisedb.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Dave,
>>>>>>>>>
>>>>>>>>> I have attached the patch for RE-SQL test cases for *Packages*
>>>>>>>>> node.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Regards,*
>>>>>>>>> *Navnath Gadakh*
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Thanks & Regards*
>>>>>>>> *Akshay Joshi*
>>>>>>>>
>>>>>>>> *Sr. Software Architect*
>>>>>>>> *EnterpriseDB Software India Private Limited*
>>>>>>>> *Mobile: +91 976-788-8246*
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Dave Page
>>>>>>> VP, Chief Architect, Tools & Installers
>>>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>
>>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>>> Twitter: @pgsnake
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Regards,*
>>>>>> *Navnath Gadakh*
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dave Page
>>>>> VP, Chief Architect, Tools & Installers
>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>> Blog: http://pgsnake.blogspot.com
>>>>> Twitter: @pgsnake
>>>>>
>>>>
>>>>
>>>> --
>>>> *Regards,*
>>>> *Navnath Gadakh*
>>>>
>>>
>>>
>>> --
>>> *Thanks & Regards*
>>> *Akshay Joshi*
>>>
>>> *Sr. Software Architect*
>>> *EnterpriseDB Software India Private Limited*
>>> *Mobile: +91 976-788-8246*
>>>
>>
>>
>> --
>> *Regards,*
>> *Navnath Gadakh*
>>
>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
>
> *Sr. Software Architect*
> *EnterpriseDB Software India Private Limited*
> *Mobile: +91 976-788-8246*
>


-- 
*Regards,*
*Navnath Gadakh*


msql_packages__tests_v3.patch
Description: Binary data

Re: RE-SQL tests patch for packages node

[navnath gadakh]

Hi,

Please find the modified patch.

On Mon, Sep 2, 2019 at 5:43 PM Akshay Joshi 
wrote:

> Hi Navnath
>
> Following are the review comments:
>
>- GRANT statement is not visible in RE-SQL for create and alter both.
>(May be bug in Packages please fix that too)
>
> Done.

>
>- Delete packages is missing in json file.
>
> Done.

>
>- Add test cases to revoke privileges(delete all the privileges).
>Check Languages node for reference.
>
> Done.

>
> On Mon, Sep 2, 2019 at 5:03 PM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>  Please find the patch for M-SQL test cases for *Packages*
>> module.
>>
>> Thanks!
>>
>> On Fri, Jul 12, 2019 at 4:02 PM Dave Page 
>> wrote:
>>
>>> Thanks, applied.
>>>
>>> On Fri, Jul 12, 2019 at 11:24 AM navnath gadakh <
>>> navnath.gad...@enterprisedb.com> wrote:
>>>
>>>> Hi Dave,
>>>>
>>>>  Please find the modified patch for packages as test cases were
>>>> failing on some servers.
>>>> Thanks!
>>>>
>>>>
>>>> On Thu, Jul 11, 2019 at 1:53 PM Dave Page 
>>>> wrote:
>>>>
>>>>> Thanks, applied.
>>>>>
>>>>> On Thu, Jul 11, 2019 at 8:07 AM Akshay Joshi <
>>>>> akshay.jo...@enterprisedb.com> wrote:
>>>>>
>>>>>> Hi Navnath
>>>>>>
>>>>>> I have tested the patch and it is not working for EPAS 9.4, 9.5 and
>>>>>> 9.6. Attached is the modified patch which fix the issue.
>>>>>> Please work on child node (functions, procedure and variables) of
>>>>>> Packages on top of modified patch.
>>>>>>
>>>>>> On Wed, Jul 10, 2019 at 8:25 PM navnath gadakh <
>>>>>> navnath.gad...@enterprisedb.com> wrote:
>>>>>>
>>>>>>> Hi Dave,
>>>>>>>
>>>>>>> I have attached the patch for RE-SQL test cases for *Packages*
>>>>>>> node.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> --
>>>>>>> *Regards,*
>>>>>>> *Navnath Gadakh*
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Thanks & Regards*
>>>>>> *Akshay Joshi*
>>>>>>
>>>>>> *Sr. Software Architect*
>>>>>> *EnterpriseDB Software India Private Limited*
>>>>>> *Mobile: +91 976-788-8246*
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dave Page
>>>>> VP, Chief Architect, Tools & Installers
>>>>> EnterpriseDB: http://www.enterprisedb.com
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>> Blog: http://pgsnake.blogspot.com
>>>>> Twitter: @pgsnake
>>>>>
>>>>
>>>>
>>>> --
>>>> *Regards,*
>>>> *Navnath Gadakh*
>>>>
>>>
>>>
>>> --
>>> Dave Page
>>> VP, Chief Architect, Tools & Installers
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>
>>
>> --
>> *Regards,*
>> *Navnath Gadakh*
>>
>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
>
> *Sr. Software Architect*
> *EnterpriseDB Software India Private Limited*
> *Mobile: +91 976-788-8246*
>


-- 
*Regards,*
*Navnath Gadakh*


msql_packages_v2.patch
Description: Binary data

Re: RE-SQL tests patch for packages node

[navnath gadakh]

Hi Dave,
 Please find the patch for M-SQL test cases for *Packages* module.

Thanks!

On Fri, Jul 12, 2019 at 4:02 PM Dave Page 
wrote:

> Thanks, applied.
>
> On Fri, Jul 12, 2019 at 11:24 AM navnath gadakh <
> navnath.gad...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>>  Please find the modified patch for packages as test cases were
>> failing on some servers.
>> Thanks!
>>
>>
>> On Thu, Jul 11, 2019 at 1:53 PM Dave Page 
>> wrote:
>>
>>> Thanks, applied.
>>>
>>> On Thu, Jul 11, 2019 at 8:07 AM Akshay Joshi <
>>> akshay.jo...@enterprisedb.com> wrote:
>>>
>>>> Hi Navnath
>>>>
>>>> I have tested the patch and it is not working for EPAS 9.4, 9.5 and
>>>> 9.6. Attached is the modified patch which fix the issue.
>>>> Please work on child node (functions, procedure and variables) of
>>>> Packages on top of modified patch.
>>>>
>>>> On Wed, Jul 10, 2019 at 8:25 PM navnath gadakh <
>>>> navnath.gad...@enterprisedb.com> wrote:
>>>>
>>>>> Hi Dave,
>>>>>
>>>>> I have attached the patch for RE-SQL test cases for *Packages*
>>>>> node.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> *Regards,*
>>>>> *Navnath Gadakh*
>>>>>
>>>>
>>>>
>>>> --
>>>> *Thanks & Regards*
>>>> *Akshay Joshi*
>>>>
>>>> *Sr. Software Architect*
>>>> *EnterpriseDB Software India Private Limited*
>>>> *Mobile: +91 976-788-8246*
>>>>
>>>
>>>
>>> --
>>> Dave Page
>>> VP, Chief Architect, Tools & Installers
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>
>>
>> --
>> *Regards,*
>> *Navnath Gadakh*
>>
>
>
> --
> Dave Page
> VP, Chief Architect, Tools & Installers
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>


-- 
*Regards,*
*Navnath Gadakh*


msql_tests_packages_v1.patch
Description: Binary data

Re: RESQL test cases for view node

[navnath gadakh]

Usman, you used a view name like "testview_12345678", can you please use it
like "testview_$%{}[]()&*^!@""'`\/#" to cover special chars scenarios.

Thanks!

On Fri, Jul 19, 2019 at 8:27 PM Usman Muzaffar <
usman.muzaf...@enterprisedb.com> wrote:

> Hi Hackers,
>
> Please find here attached patch for reverse engineering test cases for
> view node.
> Please review it and give your feedback.
>
> --
>
>
> Thanks,
>
> Usman Muzaffar
> QA Team
> EnterpriseDB Corporation
>


-- 
*Regards,*
*Navnath Gadakh*

Re: RE-SQL tests patch for packages node

[navnath gadakh]

Hi Dave,

 Please find the modified patch for packages as test cases were failing
on some servers.
Thanks!


On Thu, Jul 11, 2019 at 1:53 PM Dave Page 
wrote:

> Thanks, applied.
>
> On Thu, Jul 11, 2019 at 8:07 AM Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Hi Navnath
>>
>> I have tested the patch and it is not working for EPAS 9.4, 9.5 and 9.6.
>> Attached is the modified patch which fix the issue.
>> Please work on child node (functions, procedure and variables) of
>> Packages on top of modified patch.
>>
>> On Wed, Jul 10, 2019 at 8:25 PM navnath gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> I have attached the patch for RE-SQL test cases for *Packages* node.
>>>
>>> Thanks!
>>>
>>> --
>>> *Regards,*
>>> *Navnath Gadakh*
>>>
>>
>>
>> --
>> *Thanks & Regards*
>> *Akshay Joshi*
>>
>> *Sr. Software Architect*
>> *EnterpriseDB Software India Private Limited*
>> *Mobile: +91 976-788-8246*
>>
>
>
> --
> Dave Page
> VP, Chief Architect, Tools & Installers
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>


-- 
*Regards,*
*Navnath Gadakh*


re_sql_packages_tests_v2.patch
Description: Binary data

RE-SQL tests patch for packages node

[navnath gadakh]

Hi Dave,

I have attached the patch for RE-SQL test cases for *Packages* node.

Thanks!

-- 
*Regards,*
*Navnath Gadakh*


re_sql_packages_tests_v1.patch
Description: Binary data

[pgAdmin4][RM3961] - Exclude HTTPExceptions from all_exception_handler

[navnath gadakh]

Hi Hackers,
 Please find the attached patch for RM-3961.
This is improvement to commit 1f298590400cf5d2921a07e200086e16cc22f72c

Thanks!

-- 
Regards,
Navnath Gadakh


RM-3961_v1.patch
Description: Binary data

Re: Import/export servers

[navnath gadakh]

ignore previous, use self.assertEqual(a,b) instead of self.assertTrue(a ==
b)

On Tue, Nov 20, 2018 at 10:46 AM navnath gadakh <
navnath.gad...@enterprisedb.com> wrote:

> small feedback,
> In the tests, instead of self.assertTrue(a == b) use self.assertEqual(a ==
> b) which will give more info if test case fails.
>
> On Mon, Nov 19, 2018 at 8:09 PM Dave Page  wrote:
>
>> A number of people have asked for the ability to import and export server
>> definitions. It's also convenient to have such a feature in the container
>> world, where new instances of pgAdmin containers may be created on the fly.
>>
>> Here's a draft patch to allow that, including docs and a basic test.
>>
>> Review feedback please?
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
> --
> Regards,
> Navnath Gadakh
>


-- 
Regards,
Navnath Gadakh

Re: Import/export servers

[navnath gadakh]

small feedback,
In the tests, instead of self.assertTrue(a == b) use self.assertEqual(a ==
b) which will give more info if test case fails.

On Mon, Nov 19, 2018 at 8:09 PM Dave Page  wrote:

> A number of people have asked for the ability to import and export server
> definitions. It's also convenient to have such a feature in the container
> world, where new instances of pgAdmin containers may be created on the fly.
>
> Here's a draft patch to allow that, including docs and a basic test.
>
> Review feedback please?
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


-- 
Regards,
Navnath Gadakh

pgAdmin4: Patch for RM#3060

[navnath gadakh]

 Hi Dave,

   Please find the patch for function name quoting in SQL tab for
functions.(RM#3060 )

Files affected:
pgadmin/browser/server_groups/servers/databases/schemas/functions/__init__.py
pgadmin/browser/server_groups/servers/databases/schemas/functions/templates/function/pg/sql/default/get_definition.sql

I have added code for quoting string wherever needed.

Thanks Harshal for help!

-- 
Regards,
navnath


function_name_in_SQL_tab_v1.patch
Description: Binary data

Re: pgAdmin4: Random failure of FTS test cases due to improper random string creation

[Navnath Gadakh]

Hi Dave,

  Please find the attached patch. The code added to tear down the FTS
related objects. As this issue was random, I have tested this patch on all
12 servers (pg/ppas) with multiple time and got no errors.

Thanks.


On Fri, Aug 18, 2017 at 1:35 PM, Dave Page <dave.p...@enterprisedb.com>
wrote:

>
>
> On Fri, Aug 18, 2017 at 4:54 AM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> On Fri, Aug 11, 2017 at 1:24 PM, Navnath Gadakh <
>> navnath.gad...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> Please find the attached patch for UUID creation issues with
>>> test objects for FTS configurations, FTS dictionaries and FTS parsers.
>>> Previously(refer email with subject "Build failed in Jenkins:
>>> pgadmin4-master-python27 #279" and "Build failed in Jenkins:
>>> pgadmin4-master-python33 #207"), test cases were randomly failing due to
>>> repetitions of the test object names.
>>>
>>> In the old code we used some part of the string for creating a UUID
>>> string, but it seems that at some point that created string gets repeated
>>> and due to which test cases were failing as this was a random behavior, now
>>> it is fixed.
>>>
>> Navnath,
>>
>> We're still not removing the temporary objects, created by test-cases, in
>> the tear-down function.
>> We should have removed them in the tear-down function to fix the issue in
>> proper way.
>>
>> Dave - thoughts?
>>
>
> Right - it only seems to be FTS and FDW related objects that suffer from
> this problem from what I can see, so I assume we're getting it right for
> everything else by removing objects in the tear-down.
>
> --
> Dave Page
> VP, Chief Architect, Tools & Installers
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>



-- 
Regards,
Navnath Gadakh

EnterpriseDB Corporation
The Enterprise PostgreSQL Company


fts_teardown_issue_v2.patch
Description: Binary data

Re: pgAdmin4: Random failure of FTS test cases due to improper random string creation

[Navnath Gadakh]

Hi Ashesh,

   Please look into this as Dave is on leave.

Thanks.

On Fri, Aug 11, 2017 at 1:24 PM, Navnath Gadakh <
navnath.gad...@enterprisedb.com> wrote:

> Hi Dave,
>
> Please find the attached patch for UUID creation issues with test
> objects for FTS configurations, FTS dictionaries and FTS parsers.
> Previously(refer email with subject "Build failed in Jenkins:
> pgadmin4-master-python27 #279" and "Build failed in Jenkins:
> pgadmin4-master-python33 #207"), test cases were randomly failing due to
> repetitions of the test object names.
>
> In the old code we used some part of the string for creating a UUID
> string, but it seems that at some point that created string gets repeated
> and due to which test cases were failing as this was a random behavior, now
> it is fixed.
>
> Thanks.
>
>
>
>
>
> --
> Regards,
> Navnath Gadakh
>
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
>


-- 
Regards,
Navnath Gadakh

EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Re: Build failed in Jenkins: pgadmin4-master-python33 #207

[Navnath Gadakh]

etTestCase (Get materialized view under schema node)
> ViewsDeleteTestCase (Delete materialized view under schema
> node)
> PackageDeleteTestCase (Fetch Package Node URL)
> PackageGetTestCase (Fetch Package Node URL)
> SynonymDeleteTestCase (Fetch synonym Node URL)
> ResourceGroupsPutTestCase (Put resource groups)
> PackageAddTestCase (Fetch Package Node URL)
> SynonymGetTestCase (Fetch synonym Node URL)
> ViewsUpdateTestCase (Update materialized view under schema
> node)
> ResourceGroupsAddTestCase (Add resource groups)
> ResourceGroupsDeleteTestCase (Delete resource groups)
> EventTriggerDeleteTestCase (Fetch Event Trigger Node URL)
> EventTriggerAddTestCase (Fetch Event Trigger Node URL)
>
> PostgreSQL 9.3:
>
> 151 tests passed
> 0 tests failed
> 12 tests skipped:
> PackagePutTestCase (Fetch Package Node URL)
> SynonymPutTestCase (Fetch synonym Node URL)
> ResourceGroupsGetTestCase (Get resource groups)
> SynonymAddTestCase (Default Node URL)
> PackageDeleteTestCase (Fetch Package Node URL)
> PackageGetTestCase (Fetch Package Node URL)
> SynonymDeleteTestCase (Fetch synonym Node URL)
> ResourceGroupsPutTestCase (Put resource groups)
> PackageAddTestCase (Fetch Package Node URL)
> ResourceGroupsAddTestCase (Add resource groups)
> ResourceGroupsDeleteTestCase (Delete resource groups)
> SynonymGetTestCase (Fetch synonym Node URL)
>
> PostgreSQL 10:
>
> 150 tests passed
> 1 test failed:
> FTSConfGetTestCase (Fetch FTS configuration Node URL)
> 12 tests skipped:
> PackagePutTestCase (Fetch Package Node URL)
> SynonymPutTestCase (Fetch synonym Node URL)
> ResourceGroupsGetTestCase (Get resource groups)
> SynonymAddTestCase (Default Node URL)
> PackageDeleteTestCase (Fetch Package Node URL)
> PackageGetTestCase (Fetch Package Node URL)
> SynonymDeleteTestCase (Fetch synonym Node URL)
> ResourceGroupsPutTestCase (Put resource groups)
> PackageAddTestCase (Fetch Package Node URL)
> ResourceGroupsAddTestCase (Add resource groups)
> ResourceGroupsDeleteTestCase (Delete resource groups)
> SynonymGetTestCase (Fetch synonym Node URL)
>
> EDB Postgres AS 9.4:
>
> 163 tests passed
> 0 tests failed
> 0 tests skipped
>
> EDB Postgres AS 9.3:
>
> 159 tests passed
> 0 tests failed
> 4 tests skipped:
> ResourceGroupsDeleteTestCase (Delete resource groups)
> ResourceGroupsPutTestCase (Put resource groups)
> ResourceGroupsGetTestCase (Get resource groups)
> ResourceGroupsAddTestCase (Add resource groups)
>
> EDB Postgres AS 9.5:
>
> 163 tests passed
> 0 tests failed
> 0 tests skipped
>
> EDB Postgres AS 9.2:
>
> 151 tests passed
> 0 tests failed
> 12 tests skipped:
> EventTriggerGetTestCase (Fetch Event Trigger Node URL)
> EventTriggerAddTestCase (Fetch Event Trigger Node URL)
> ResourceGroupsGetTestCase (Get resource groups)
> ViewsAddTestCase (Add materialized view under schema node)
> ViewsGetTestCase (Get materialized view under schema node)
> ResourceGroupsAddTestCase (Add resource groups)
> ResourceGroupsPutTestCase (Put resource groups)
> ViewsUpdateTestCase (Update materialized view under schema
> node)
> ViewsDeleteTestCase (Delete materialized view under schema
> node)
> ResourceGroupsDeleteTestCase (Delete resource groups)
> EventTriggerDeleteTestCase (Fetch Event Trigger Node URL)
> EventTriggerPutTestCase (Fetch Event Trigger Node URL)
>
> ==
>
> ERROR: Error detected when running the Python tests.
> ERROR: Error detected when running the Python tests.
> Build step 'Execute shell' marked build as failure
>
>
Thanks.

-- 
Regards,
Navnath Gadakh

EnterpriseDB Corporation
The Enterprise PostgreSQL Company