Re: [pgAdmin4][Patch]: Feature test for PG Data-types in Query Tool

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(at)pgadmin(dot)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(dot)vashi(at)enterprisedb(dot)com> wrote:
> > Hi,
> >
> > Please find the attached updated patch.
> >
> > Thanks,
> > Khushboo
> >
> > On Thu, May 11, 2017 at 2:41 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> >>
> >> Hi
> >>
> >> On Thu, May 11, 2017 at 6:38 AM, Khushboo Vashi
> >> <khushboo(dot)vashi(at)enterprisedb(dot)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
>