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

Поиск
Список
Период
Сортировка
От Khushboo Vashi
Тема Re: [pgadmin-hackers] [pgAdmin4][Patch]: Feature test for PGData-types in Query Tool
Дата
Msg-id CAFOhELc0hu-d0MvxOPkyCE8O5cOKywCWy6GGhXcT8fXKQ3JkMw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [pgadmin-hackers] [pgAdmin4][Patch]: Feature test for PGData-types in Query Tool  (Dave Page <dpage@pgadmin.org>)
Ответы Re: [pgadmin-hackers] [pgAdmin4][Patch]: Feature test for PGData-types in Query Tool  (Dave Page <dpage@pgadmin.org>)
Список 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

Вложения

В списке pgadmin-hackers по дате отправления:

Предыдущее
От: Ashesh Vashi
Дата:
Сообщение: Re: [pgadmin-hackers] [pgAdmin4][PATCH] To fix the issue with Node rename
Следующее
От: Murtuza Zabuawala
Дата:
Сообщение: [pgadmin-hackers] [pgAdmin4] [PATCH] To fix issue in UPDATE Script and Primary keyorder when view data