Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bx7K7-0006Ay-NV for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 06:59:31 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bx7K6-0001z3-Fj for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 06:59:30 +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 1bx7K5-0001yx-DF for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 06:59:29 +0000 Received: from mail-qk0-x234.google.com ([2607:f8b0:400d:c09::234]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bx7K0-0005aI-O6 for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 06:59:28 +0000 Received: by mail-qk0-x234.google.com with SMTP id n189so75700725qke.0 for ; Wed, 19 Oct 2016 23:59:24 -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=J1fOdTr2XO44rMekZJavKJC+Vf/xd3RB7E6jWOpXKGs=; b=N/n3yptI2WM1AKGuFCiiVj7ZRz06MI+csiQvjdMom9kgsy4TX9cLiW/v6Kv4im76yg syu5sC61QSogUQx0qTgolJnT6q1hAyU894Tj07WxBupfprZt0dTOFAhyFcDiO/q5FMc7 TjZbq1d0ofGFpVriOhib4aGSy0UFZqb9MvXyj6i7BsgHvmZetEzJqgFznWm4nVyStkNO 9BzrlRTZdmkz7GpXx46LE1mHIJjbdiv9sapsmCkIlarOLbQjz0vZtcd8+2mb6ioyuo8d SXuaUAmd/QWxXZBrn9JI/yLch/9ILN9yWzmmxarJa7Q+fl8PxKrZ4XiYGJDTM87FgQNS dhqA== 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=J1fOdTr2XO44rMekZJavKJC+Vf/xd3RB7E6jWOpXKGs=; b=a3RbvcztLeNVEzDmDJdce0xN9k5nA0uYoPeFptEA8Tu/YP+Ck53WUwdRB9RkfiikHT eF9VFjHCRS9t9iUO2xJ7ekjGMt/MeBNbpDv+7kGOxUHYxnlzyvcLC+NDNB/cp9S9As5p 1242TpUV4/3j3rkWuVri6d2WrapktdoeXvzalR/+Ou+y13hW4gBi2oZxFFeY6sMCEr+w RUNrgRtavPA+XeM/7Bm+aiL+zX3hz4hUYtHoTNUizv2g6ozmqnnMi18jBPgsTN+HMqwH gMCQnGn40b9LQkpSvxCxi1ZgWsWcePwaOa9BGiRWtv6SeuDNxAgYw4GwE9o6BU0Coebc Ryaw== X-Gm-Message-State: AA6/9RmNRRnKo1Sobj6BXRnUvg8IzcJzrODPqtCFklE93cdsmDF9uKyGXCwCiwxWGWxr3aZ2sJiTTEsqZdyjoPaA X-Received: by 10.194.147.48 with SMTP id th16mr6639004wjb.68.1476946762720; Wed, 19 Oct 2016 23:59:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.172.198 with HTTP; Wed, 19 Oct 2016 23:58:51 -0700 (PDT) In-Reply-To: References: From: Surinder Kumar Date: Thu, 20 Oct 2016 12:28:51 +0530 Message-ID: Subject: Re: [pgAdmin4][Patch]: RM1728 - Properties are not refreshing after objects are edited To: Dave Page Cc: pgadmin-hackers Content-Type: multipart/mixed; boundary=089e012282b62524ea053f467759 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 --089e012282b62524ea053f467759 Content-Type: multipart/alternative; boundary=089e012282b62524e3053f467757 --089e012282b62524e3053f467757 Content-Type: text/plain; charset=UTF-8 Hi, While fixing RM1840, I found when we add new index, it doesn't add under right parent. i.e. columns collection. because wrong parent is given in response. I also verified other nodes. This issue is only with index node. Do, I need to create separate RM for this case. ? Please find attached minor patch and review. On Tue, Oct 18, 2016 at 4:03 PM, Dave Page wrote: > Thanks - applied! > > On Mon, Oct 17, 2016 at 7:48 AM, Surinder Kumar > wrote: > > On Sun, Oct 16, 2016 at 7:29 AM, Dave Page wrote: > >> > >> 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. > > > > I have fixed this issue. Now it will lookup the schema ID against the > type > > id instead of type name. > >> > >> > >> 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. > > > > It looks good to me in other nodes. > > Please find attached patch and review. > >> > >> > >> Thanks. > >> > >> > >> On Friday, October 14, 2016, Dave Page wrote: > >>> > >>> Thanks, applied. > >>> > >>> On Friday, October 14, 2016, Surinder Kumar > >>> 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 > >> > > > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > --089e012282b62524e3053f467757 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=

While fixing RM1840, I f= ound when we add new index, it doesn't add under right parent. i.e. col= umns collection. because wrong parent is given in response.
I also verified other nodes. T= his issue is only with index node.

Do, I need to create separate RM for this case. ?

Please find attached minor patch and re= view.

= On Tue, Oct 18, 2016 at 4:03 PM, Dave Page <dpage@pgadmin.org> wrote:
Thanks - applied!

On Mon, Oct 17, 2016 at 7:48 AM, Surinder Kumar
<surinder.kumar@enterprisedb.com> wrote:
> On Sun, Oct 16, 2016 at 7:29 AM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> 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 th= e type
>> name, which a) isn't in the posted data so gives a 500 respons= e, and b)
>> wouldn't be safe anyway, if there were types with the same nam= e in multiple
>> schemas.
>
> I have fixed this issue. Now it will lookup the schema ID against the = type
> id instead of type name.
>>
>>
>> Actually, it looks like that's an issue when creating a type t= oo - that is
>> also using an unsafe schema lookup.
>>
>> Please fix this ASAP (i.e. Monday) and double check to ensure we&#= 39;re not
>> doing any more unsafe lookups like this.
>
> It looks good to me in other nodes.
> Please find attached patch and review.
>>
>>
>> Thanks.
>>
>>
>> On Friday, October 14, 2016, Dave Page <dpage@pgadmin.org> wrote:
>>>
>>> Thanks, applied.
>>>
>>> On Friday, October 14, 2016, Surinder Kumar
>>> <surinde= r.kumar@enterprisedb.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 pane= l.
>>>> Fixed in Domains, Collation, Types, Views & Table node= .
>>>>
>>>> 2) Incorrect parent id of object node is returned from nod= es method due
>>>> to which wrong parent id is passed while updating object a= nd
>>>> thus node didn't get refreshed.
>>>> Fixed in FTS Configuration, FTS Parser nodes.
>>>>
>>>> Also, I have kept changes of first patch which are essenti= al 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 <dpage@pgadmin.org> 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 <dpage@pgadmin.org> wrote:
>>>>> > Thanks, applied.
>>>>> >
>>>>> > On Fri, Sep 23, 2016 at 12:05 PM, Surinder Kumar<= br> >>>>> > <surinder.kumar@enterprisedb.com> wrote:
>>>>> >> Hi,
>>>>> >>
>>>>> >> Please find updated patch with changes:
>>>>> >> 1) On debugging through JS files, the issue w= as in synonym update
>>>>> >> method
>>>>> >> which wasn't returning node object.
>>>>> >> 2) retrieving schema name in node.sql for cre= ating node object in
>>>>> >> update
>>>>> >> method.
>>>>> >>
>>>>> >> Please review and let me know for comments. >>>>> >>
>>>>> >> On Fri, Sep 23, 2016 at 2:44 PM, Dave Page &l= t;dpage@pgadmin.org>
>>>>> >> 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 th= en again select the node
>>>>> >>> > updated to
>>>>> >>> > refresh the panel. but it needs some= delay of few milliseconds
>>>>> >>> > between
>>>>> >>> > deselect and select to fix this issu= e.
>>>>> >>> >
>>>>> >>> > Please find attached patch and revie= w.
>>>>> >>>
>>>>> >>> This does not resolve the issue for me. I= tested using a synonym to
>>>>> >>> a
>>>>> >>> package on EPAS 9.5, by changing the targ= et package name.
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> Dave Page
>>>>> >>> Blog: http://pgsnake.blogspot.com >>>>> >>> Twitter: @pgsnake
>>>>> >>>
>>>>> >>> EnterpriseDB UK: http://www.enterprised= b.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
>>
>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--089e012282b62524e3053f467757-- --089e012282b62524ea053f467759 Content-Type: application/octet-stream; name="RM1728_fix_for_index_node.patch" Content-Disposition: attachment; filename="RM1728_fix_for_index_node.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iuhzy3kl0 ZGlmZiAtLWdpdCBhL3dlYi9wZ2FkbWluL2Jyb3dzZXIvc2VydmVyX2dyb3Vw cy9zZXJ2ZXJzL2RhdGFiYXNlcy9zY2hlbWFzL3RhYmxlcy9pbmRleGVzL19f aW5pdF9fLnB5IGIvd2ViL3BnYWRtaW4vYnJvd3Nlci9zZXJ2ZXJfZ3JvdXBz L3NlcnZlcnMvZGF0YWJhc2VzL3NjaGVtYXMvdGFibGVzL2luZGV4ZXMvX19p bml0X18ucHkKaW5kZXggODE5ZjgzYy4uNGYyMGQ2MSAxMDA2NDQKLS0tIGEv d2ViL3BnYWRtaW4vYnJvd3Nlci9zZXJ2ZXJfZ3JvdXBzL3NlcnZlcnMvZGF0 YWJhc2VzL3NjaGVtYXMvdGFibGVzL2luZGV4ZXMvX19pbml0X18ucHkKKysr IGIvd2ViL3BnYWRtaW4vYnJvd3Nlci9zZXJ2ZXJfZ3JvdXBzL3NlcnZlcnMv ZGF0YWJhc2VzL3NjaGVtYXMvdGFibGVzL2luZGV4ZXMvX19pbml0X18ucHkK QEAgLTYyMyw3ICs2MjMsNyBAQCBjbGFzcyBJbmRleGVzVmlldyhQR0NoaWxk Tm9kZVZpZXcpOgogICAgICAgICAgICAgcmV0dXJuIGpzb25pZnkoCiAgICAg ICAgICAgICAgICAgbm9kZT1zZWxmLmJsdWVwcmludC5nZW5lcmF0ZV9icm93 c2VyX25vZGUoCiAgICAgICAgICAgICAgICAgICAgIGlkeCwKLSAgICAgICAg ICAgICAgICAgICAgc2NpZCwKKyAgICAgICAgICAgICAgICAgICAgdGlkLAog ICAgICAgICAgICAgICAgICAgICBkYXRhWyduYW1lJ10sCiAgICAgICAgICAg ICAgICAgICAgIGljb249Imljb24taW5kZXgiCiAgICAgICAgICAgICAgICAg KQo= --089e012282b62524ea053f467759 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers --089e012282b62524ea053f467759--