Thanks - patch applied. I added your notes about the reason for the
sleep as a comment in the code.

On Fri, May 26, 2017 at 3:13 AM, Khushboo Vashi
<khushboo.va...@enterprisedb.com> wrote:
> Hi Dave,
>
> Please find the attached updated patch with little modification.
>
> Thanks,
> Khushboo
> On Fri, May 26, 2017 at 1:27 AM, Dave Page <dp...@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.va...@enterprisedb.com> wrote:
>> > Hi,
>> >
>> > Please find the attached updated patch.
>> >
>> > Thanks,
>> > Khushboo
>> >
>> > On Thu, May 11, 2017 at 2:41 PM, Dave Page <dp...@pgadmin.org> wrote:
>> >>
>> >> Hi
>> >>
>> >> On Thu, May 11, 2017 at 6:38 AM, Khushboo Vashi
>> >> <khushboo.va...@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
>
>



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

Reply via email to