Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f3Lbj-0000SK-0C for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Apr 2018 13:04:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f3Lbh-0003tH-TE for pgadmin-hackers@arkaria.postgresql.org; Tue, 03 Apr 2018 13:04:13 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f3Lbh-0003sz-BC for pgadmin-hackers@lists.postgresql.org; Tue, 03 Apr 2018 13:04:13 +0000 Received: from mail-yb0-x230.google.com ([2607:f8b0:4002:c09::230]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1f3LbR-0007Ns-Lw for pgadmin-hackers@postgresql.org; Tue, 03 Apr 2018 13:04:11 +0000 Received: by mail-yb0-x230.google.com with SMTP id y189-v6so269821ybc.7 for ; Tue, 03 Apr 2018 06:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+x1iDDvQcaoYvAqaM1e1c7TNCJCsZfW75Y6H0y5Recw=; b=RtO1Wmd+BoBDEH7ry2q917P2sk3VExnoiUaJatvPFuD1YZvgifdFNCyjzhyiASxeRV CHRtGZRGq1/HJ/h/GgyscJl/ZiibZmnccde0eZo7OmRSdg73cfRAFkpjwb8EfrZPb4yc l/Bj80juX/+bvAPpooxFKNiP+GFyYq3TsQ0NsSpbKz0V8JBHwJfFn06cc2er99fXIO8w 9hyOZwX3KNUL2pVPiA+s3hGA+rrhhfq9m8KMcqJwzX+HIe4Axgn/LZ1sSNF91rxC02zi udVS5jLqcOiaQgNGx/3On21bRKwshhmQTd83rjVWbdBPHR6HLp20ZU+oGARp0sZoBKaY g4qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+x1iDDvQcaoYvAqaM1e1c7TNCJCsZfW75Y6H0y5Recw=; b=QRgANjQg1+nsk0FbRI9eEDiTuAkysDguNCjg4JQteSSVvbWiYwamsbRW85Stf9gbeX V7ArgZLA7LxT5ShXA4klJcnMeJjVtuEizhcD1zdNwR9qLHEDMP8V+KZI1DquE+NRKSwD aaQMIzk5wi+JU07+Knts5D1yxNJnExs6hAZkzJtKZRpIh8YyCtQCJZ9p6mmLK//j51Ho OkMVxevN72vxunnzGQbScpniYf/uwzy8VZGFh7nrpJ204h37bTqFbaLMh6QR2+4D39af bNu4xgKzBhw7h6MqjnulyI7B0EHSuqqZLMe162nO5oU2qfVFYzHbk6P7iXSzFy4TOlAo KaRg== X-Gm-Message-State: ALQs6tDSC8zzxLBjBphWM4ic4m1S9oM6h5DyPlUrnt7WcYlApqD2kHfy l0mjgen3s9J1JgZYbxtOvbIdxMCWA/abUq0U7YTQOQ== X-Google-Smtp-Source: AIpwx49+IixW4ZtrSRE2yU/s58Up/wi23Zi8zjIKfJ+0WAM4UgjclUxh0wR6uN6j/z586JoWCJ8hOiLcIjG2k8x9xfM= X-Received: by 2002:a25:4003:: with SMTP id n3-v6mr7678708yba.390.1522760635903; Tue, 03 Apr 2018 06:03:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.174.22 with HTTP; Tue, 3 Apr 2018 06:03:55 -0700 (PDT) In-Reply-To: References: From: Harshal Dhumal Date: Tue, 3 Apr 2018 18:33:55 +0530 Message-ID: Subject: Re: Bug #3083 fix To: Dave Page Cc: Joao De Almeida Pereira , Akshay Joshi , Neethu Mariya Joy , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000c80ec20568f156be" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000c80ec20568f156be Content-Type: text/plain; charset="UTF-8" -- *Harshal Dhumal* *Sr. Software Engineer* EnterpriseDB India: http://www.enterprisedb.com The Enterprise PostgreSQL Company On Tue, Apr 3, 2018 at 6:10 PM, Dave Page wrote: > Argh, managed to send before I finished typing... > > On Tue, Apr 3, 2018 at 1:38 PM, Dave Page wrote: > >> Hi >> >> On Thu, Mar 29, 2018 at 4:29 PM, Joao De Almeida Pereira < >> jdealmeidapereira@pivotal.io> wrote: >> >>> Hi Dave, >>> That looks like in the surrounding area of the change. We run our >>> pipeline and everything was green. >>> Can you provide more details, which python version are you using? OS? >>> >> >> That was on my travel laptop, which is macOS Sierra with the Apple >> supplied Python 2.7. >> >> Interestingly, I'm on my dev laptop today (same OS and Python) and it's >> working just fine. The difference is that the travel machine is a 12" >> Macbook, whilst the dev machine is >> > > a 15" MacBook Pro with 2 24" external monitors. That makes me wonder if > the small screen size is causing a problem with this test, something we > have seen before. > > Yes, screen size does cause problem. Slick grid does not render all columns if viewport is not wide enough (like it does for rows). Remaining columns would render when user scrolls right. To avoid similar problem in datatype feature test (commit: 88bcd3b5129db88975421e26c1bf188daf4892f9 ) I have executed queries in batch to limit number of columns in single query result. > >> >>> >>> Thanks >>> Joao >>> >>> On Thu, Mar 29, 2018 at 9:03 AM Dave Page wrote: >>> >>>> Hi >>>> >>>> On Wed, Mar 28, 2018 at 7:06 PM, Joao De Almeida Pereira < >>>> jdealmeidapereira@pivotal.io> wrote: >>>> >>>>> Hey Akshay and Neethu >>>>> >>>>> We refactored the patch to add tests for the resize feature. We were >>>>> able to write test cases for the drag event by using spies and setting the >>>>> rect dimensions. In cases like this, we can just test some components in >>>>> order to have enough confidence in the code. So we isolated the function >>>>> that implements the behavior of this feature and tested that it was >>>>> performing as expected. >>>>> >>>>> We ran the patch through the pipelines and all of the tests passed. >>>>> >>>> >>>> I'm consistently seeing the feature test failure below with this patch >>>> applied: >>>> >>>> ====================================================================== >>>> FAIL: runTest (pgadmin.feature_tests.view_da >>>> ta_dml_queries.CheckForViewDataTest) >>>> Validate Insert, Update operations in View/Edit data with given test >>>> data >>>> ---------------------------------------------------------------------- >>>> Traceback (most recent call last): >>>> File "/Users/dpage/git/pgadmin4/web/pgadmin/feature_tests/view_data_dml_queries.py", >>>> line 125, in runTest >>>> self._verify_row_data(True) >>>> File "/Users/dpage/git/pgadmin4/web/pgadmin/feature_tests/view_data_dml_queries.py", >>>> line 325, in _verify_row_data >>>> self.assertEquals(cells[idx], config_data[str(idx)][1]) >>>> AssertionError: u'[null]' != u'1' >>>> - [null] >>>> + 1 >>>> >>>> >>>> -- >>>> 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 > --000000000000c80ec20568f156be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
--=C2=A0<= /div>
Harshal Dhumal
Sr. Software Engineer

EnterpriseDB India:=C2=A0ht= tp://www.enterprisedb.com
The Enterpr= ise PostgreSQL Company
=

On Tue, Apr 3, 2018 at 6:10 PM, Dave Page <= dpage@pgadmin.org> wrote:
<= div dir=3D"ltr">Argh, managed to send before I finished typing...

On Tue= , Apr 3, 2018 at 1:38 PM, Dave Page <dpage@pgadmin.org> wrot= e:
Hi

On= Thu, Mar 29, 2018 at 4:29 PM, Joao De Almeida Pereira &l= t;jdealme= idapereira@pivotal.io> wrote:
Hi Dave,
That looks like in the surrounding area of= the change. We run our pipeline and everything was green.
Can yo= u provide more details, which python version are you using? OS?
=

That was on my travel laptop, which= is macOS Sierra with the Apple supplied Python 2.7.

Interestingly, I'm on my dev laptop today (same OS and Python) and i= t's working just fine. The difference is that the travel machine is a 1= 2" Macbook, whilst the dev machine is=C2=A0

a 15" MacBook Pro with 2 24"= external monitors. That makes me wonder if the small screen size is causin= g a problem with this test, something we have seen before.
=C2=A0

Yes, screen size does cause problem. Slick grid does = not render all columns if viewport is not wide enough (like it does for row= s).
Remaining columns would render when user scrolls right.
To avoid similar problem in datatype feature test (commit: 88bcd3b= 5129db88975421e26c1bf188daf4892f9) I have executed
queries in b= atch to limit number of columns in single query result.

=
=C2=A0
=C2=A0<= /div>

Th= anks
Joao

On Thu, Mar 29, 2018 at 9:03 AM Dave Page <dpage@pgadmin.org> wrote:
Hi

<= div class=3D"gmail_extra">
On Wed, Mar 28, 2018 a= t 7:06 PM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.i= o> wrote:
Hey Akshay and Neethu

We refactored t= he patch to add tests for the resize feature.=C2=A0 We were able to write t= est cases for the drag event by using spies and setting the rect dimensions= .=C2=A0 In cases like this, we can just test some components in order to ha= ve enough confidence in the code.=C2=A0 So we isolated the function that im= plements the behavior of this feature and tested that it was performing as = expected.

We ran the patch through the pipelines a= nd all of the tests passed.

I'm consistently seeing the feature test failure below with = this patch applied:

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: runTest (pg= admin.feature_tests.view_data_dml_queries.CheckForViewDataTest)
Validate Insert, Update operations in View/Edit data with given te= st data
----------------------------------------------------= ------------------
Traceback (most recent call last):
<= div>=C2=A0 File "/Users/dpage/git/pgadmin4/web/pgadmin/feature_te= sts/view_data_dml_queries.py", line 125, in runTest
=C2= =A0 =C2=A0 self._verify_row_data(True)
=C2=A0 File "/Users/d= page/git/pgadmin4/web/pgadmin/feature_tests/view_data_dml_queries= .py", line 325, in _verify_row_data
=C2=A0 =C2=A0 self.asser= tEquals(cells[idx], config_data[str(idx)][1])
AssertionError: u&#= 39;[null]' !=3D u'1'
- [null]
+ 1


--
Da= ve Page
Blog: = http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK= : http://www.ente= rprisedb.com
The Enterprise PostgreSQL Company



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
<= /div>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twi= tter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Pos= tgreSQL Company

--000000000000c80ec20568f156be--