Re: [pgadmin-hackers] [pgAdmin4][Patch]: Feature test for PGData-types in Query Tool - Mailing list pgadmin-hackers

From Khushboo Vashi
Subject Re: [pgadmin-hackers] [pgAdmin4][Patch]: Feature test for PGData-types in Query Tool
Date
Msg-id CAFOhELc0hu-d0MvxOPkyCE8O5cOKywCWy6GGhXcT8fXKQ3JkMw@mail.gmail.com
Whole thread Raw
In response to Re: [pgadmin-hackers] [pgAdmin4][Patch]: Feature test for PGData-types in Query Tool  (Dave Page <dpage@pgadmin.org>)
Responses Re: [pgadmin-hackers] [pgAdmin4][Patch]: Feature test for PGData-types in Query Tool
List pgadmin-hackers
Hi Dave,

Please find the attached updated patch with little modification.

Thanks,
Khushboo
On Fri, May 26, 2017 at 1:27 AM, Dave Page <dpage@pgadmin.org> wrote:
Hi

What are the sleeps in pgadmin_page.py for? Can we get rid of them?

For the long text, if we try to execute send_keys and perform back to back, then the actions are not executed properly as the driver can send only 50 to 60 characters.
So to avoid this I have put sleep on the basis of content length. 

In case of other elements (like textbox etc.), we can compare the length of the element value and given content, so we can use wait here. But for code-mirror we don't have value property so, can't perform comparison of length. For this reason wait has not been implemented.
 
On Thu, May 25, 2017 at 6:06 AM, Khushboo Vashi
<khushboo.vashi@enterprisedb.com> wrote:
> Hi,
>
> Please find the attached updated patch.
>
> Thanks,
> Khushboo
>
> On Thu, May 11, 2017 at 2:41 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> On Thu, May 11, 2017 at 6:38 AM, Khushboo Vashi
>> <khushboo.vashi@enterprisedb.com> wrote:
>>>
>>> Hi,
>>>
>>> As we have been facing many issues with different data-type display in
>>> Query Tool output, Dave suggested to write the feature test for the same.
>>>
>>> I have started with some basic set of data-type values and will add more.
>>> Please find the attached initial patch for the same.
>>
>>
>> Some thoughts:
>>
>> - Instead of sleeping, which is almost always a bad design, can we wait
>> for objects to appear?
>>
> Fixed
>>
>> - Currently you're testing each datatype with an individual query, e.g.
>>
>> SELECT 32768;
>>
>> I would suggest we test all datatypes at once, e.g.
>>
>> SELECT 32768, 43723489023489, '2017-09-12 15:34:11', 12345.56;
>>
>> etc. That will massively reduce the time taken to execute the tests (which
>> is a big concern).
>>
> Fixed
>>
>> - Shouldn't we be casting the values in the SELECT, so we (and the
>> database) know exactly what we're expecting? e.g.
>>
> Fixed
>>
>> SELECT 32768::int, 43723489023489::bigint, '2017-09-12
>> 15:34:11':timestamp, 12345.56::numeric(8,4);
>>
>> That would also allow us to verify the type name displayed in the column
>> headers.
>>
>> 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

Attachment

pgadmin-hackers by date:

Previous
From: Ashesh Vashi
Date:
Subject: Re: [pgadmin-hackers] [pgAdmin4][PATCH] To fix the issue with Node rename
Next
From: Murtuza Zabuawala
Date:
Subject: [pgadmin-hackers] [pgAdmin4] [PATCH] To fix issue in UPDATE Script and Primary keyorder when view data