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
