Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bvajr-0002Wg-Ul for pgadmin-hackers@arkaria.postgresql.org; Sun, 16 Oct 2016 01:59:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bvajq-0005KO-Rc for pgadmin-hackers@arkaria.postgresql.org; Sun, 16 Oct 2016 01:59:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bvajo-0005KD-WE for pgadmin-hackers@postgresql.org; Sun, 16 Oct 2016 01:59:45 +0000 Received: from mail-it0-x22f.google.com ([2607:f8b0:4001:c0b::22f]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bvajk-00058Z-A8 for pgadmin-hackers@postgresql.org; Sun, 16 Oct 2016 01:59:43 +0000 Received: by mail-it0-x22f.google.com with SMTP id k64so5827207itb.0 for ; Sat, 15 Oct 2016 18:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A2b9p1EIdty/sdXzVaJpRulzpR1KUrR990MJj3Qp6Wc=; b=qceKf79agX1a9ReFx5jQkNYdKXnOfOjdylreAHGK3SF/Tnw8CwSmmo+HwrdjjqwRzi JD2xpxP6sK/5SIpiLfBzB0gpKmX0tQRu6JZMX1zc1WolglXsRoC/5p7v+Jmrt4MRrgWN r1IUg6hWbpQUJbxEHNxQPcP41TzRXRRP5lgt8J0pvPH8pAGZAl9mbxzNTFB7x5/vMOnc jrXggoWVkIRXokcG31FHSHwOWqgx9Xxp093otPe3CJyeynrIQgwSfnKA0oFGAWqzb1+d PAG58yK9S+hy4qGfBASE/nJtxvBuIk0iK0zikXcCP3+VAxnMiGcvVpqSpkMqHKK/wRI7 +tCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A2b9p1EIdty/sdXzVaJpRulzpR1KUrR990MJj3Qp6Wc=; b=MlNeTTYUbjueJ5i1LtMkah5/zvMK+eS3exF1wkHa54IDDiS88SLvun8hQrhu+YoGXS UKlyu66zRHIFxAnnM3ZtP6ZGRzFAPijd2sIRDUion6gfe3rCj831r09CR4NWTHmCezN1 rURabKKT5bqVbbMJRsk6uwwj/sdO4s3Y+TipwySE907DdJMVPOZ/MEMJTROIX6GlUGOG sUCNLPuwmuyDTqnLHwwq6y//ip7XwlFR3JCwI7nlYpe24MNPYAilOgmJL9K8uKwp9XWp EfQn0Ve68jns8mWXVoKG5BMZdyW5inLpkgO5mfsZSUzhrwYxcG19WxsmrPQnAnYCcPlQ cjHw== X-Gm-Message-State: AA6/9RlWmUwOQdUOvUdFJev6GitdDDMoLf8HN3JM/HMXKLinjq0mys3RhNtcRVl72vVdRMIdDJmP8Pw+OfByTw== X-Received: by 10.36.149.193 with SMTP id m184mr3547533itd.94.1476583178071; Sat, 15 Oct 2016 18:59:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.146.135 with HTTP; Sat, 15 Oct 2016 18:59:37 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Sun, 16 Oct 2016 02:59:37 +0100 Message-ID: Subject: Re: [pgAdmin4][Patch]: RM1728 - Properties are not refreshing after objects are edited To: Surinder Kumar Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary=94eb2c08b3c4cf84fe053ef1cf46 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --94eb2c08b3c4cf84fe053ef1cf46 Content-Type: text/plain; charset=UTF-8 Hi I just found a case where this patch is broken - if you update the comment on a type, it looks like it tried to lookup the schema ID using the type name, which a) isn't in the posted data so gives a 500 response, and b) wouldn't be safe anyway, if there were types with the same name in multiple schemas. Actually, it looks like that's an issue when creating a type too - that is also using an unsafe schema lookup. Please fix this ASAP (i.e. Monday) and double check to ensure we're not doing any more unsafe lookups like this. Thanks. On Friday, October 14, 2016, Dave Page wrote: > Thanks, applied. > > On Friday, October 14, 2016, Surinder Kumar com > > wrote: > >> Hi >> >> *Following are the issues fixed in nodes:* >> >> 1) If we create/update a node with non-default schema, It should return >> selected schema id in return response. but default schema id is returned >> every time due to which it throws error in properties panel. >> Fixed in Domains, Collation, Types, Views & Table node. >> >> 2) Incorrect parent id of object node is returned from *nodes method* >> due to which wrong parent id is passed while updating object and >> thus node didn't get refreshed. >> Fixed in FTS Configuration, FTS Parser nodes. >> >> Also, I have kept changes of first patch which are essential to refresh >> node every time. Without that patch nodes properties panel updates only >> sometimes. >> >> Please find attached patch. Please review and let me know for comments. >> >> Thanks >> Surinder Kumar >> >> >> >> On Fri, Sep 23, 2016 at 6:00 PM, Dave Page wrote: >> >>> Umm, no it wasn't - sorry. >>> >>> I see the same issue with Types. Can you fix that, and check all other >>> nodes as well please? >>> >>> Thanks. >>> >>> On Fri, Sep 23, 2016 at 1:29 PM, Dave Page wrote: >>> > Thanks, applied. >>> > >>> > On Fri, Sep 23, 2016 at 12:05 PM, Surinder Kumar >>> > wrote: >>> >> Hi, >>> >> >>> >> Please find updated patch with changes: >>> >> 1) On debugging through JS files, the issue was in synonym update >>> method >>> >> which wasn't returning node object. >>> >> 2) retrieving schema name in node.sql for creating node object in >>> update >>> >> method. >>> >> >>> >> Please review and let me know for comments. >>> >> >>> >> On Fri, Sep 23, 2016 at 2:44 PM, Dave Page wrote: >>> >>> >>> >>> Hi >>> >>> >>> >>> On Fri, Sep 23, 2016 at 7:39 AM, Surinder Kumar >>> >>> wrote: >>> >>> > Hi >>> >>> > >>> >>> > Issue: >>> >>> > on updating node, we deselect and then again select the node >>> updated to >>> >>> > refresh the panel. but it needs some delay of few milliseconds >>> between >>> >>> > deselect and select to fix this issue. >>> >>> > >>> >>> > Please find attached patch and review. >>> >>> >>> >>> This does not resolve the issue for me. I tested using a synonym to a >>> >>> package on EPAS 9.5, by changing the target package name. >>> >>> >>> >>> >>> >>> -- >>> >>> 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 >>> >> >> > > -- > 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 --94eb2c08b3c4cf84fe053ef1cf46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi

I just found a case where this patch is broken - if y= ou update the comment on a type, it looks like it tried to lookup the schem= a ID using the type name, which a) isn't in the posted data so gives a = 500 response, and b) wouldn't be safe anyway, if there were types with = the same name in multiple schemas.

Actually, it lo= oks like that's an issue when creating a type too - that is also using = an unsafe schema lookup.

Please fix this ASAP (i.e= . Monday) and double check to ensure we're not doing any more unsafe lo= okups like this.

Thanks.

On Friday, October= 14, 2016, Dave Page <dpage@pgadmin= .org> wrote:
Thanks, applied.
<= br>On Friday, October 14, 2016, Surinder Kumar <surinder.kumar@enterprisedb.com> wrote:
Hi

<= b>Following are the issues fixed in nodes:

1) If we create/update a node = with non-default schema, It should return selected schema id in return resp= onse. but default schema id is returned every time due to which it throws e= rror in properties panel.
Fixed in Domains, Collation, Types, Views & Table node.

2) Incorrect parent id of obj= ect node is returned from nodes method due to which wrong parent id = is passed while updating object and=C2=A0
thus node didn't get refreshed.
Fixed in FTS Configuration,= FTS Parser nodes.

Also, = I have kept changes of first patch which are essential to refresh node ever= y time. Without that patch nodes properties panel updates only sometimes.

Please find attached patch= . Please review and let me know for comments.

Thanks
Surinder Kumar



On Fri, Sep 23, 2016 at 6:00 PM, Dave Page <dpage= @pgadmin.org> wrote:
Umm, n= o it wasn't - sorry.

I see the same issue with Types. Can you fix that, and check all other
nodes as well please?

Thanks.

On Fri, Sep 23, 2016 at 1:29 PM, Dave Page <dpage@pgadmin.org>= wrote:
> Thanks, applied.
>
> On Fri, Sep 23, 2016 at 12:05 PM, Surinder Kumar
> <surinder.kumar@enterprisedb.com> wrote:
>> Hi,
>>
>> Please find updated patch with changes:
>> 1) On debugging through JS files, the issue was in synonym update = method
>> which wasn't returning node object.
>> 2) retrieving schema name in node.sql for creating node object in = update
>> method.
>>
>> Please review and let me know for comments.
>>
>> On Fri, Sep 23, 2016 at 2:44 PM, Dave Page <dpage@pgadmin.or= g> wrote:
>>>
>>> Hi
>>>
>>> On Fri, Sep 23, 2016 at 7:39 AM, Surinder Kumar
>>> <surinder.kumar@enterprisedb.com> wrote:
>>> > Hi
>>> >
>>> > Issue:
>>> > on updating node, we deselect and then again select the n= ode updated to
>>> > refresh the panel. but it needs some delay of few millise= conds between
>>> > deselect and select to fix this issue.
>>> >
>>> > Please find attached patch and review.
>>>
>>> This does not resolve the issue for me. I tested using a synon= ym to a
>>> package on EPAS 9.5, by changing the target package name.
>>>
>>>
>>> --
>>> 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



--
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
Twit= ter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Post= greSQL Company

--94eb2c08b3c4cf84fe053ef1cf46--