Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d6fO0-0007Oz-Ag for pgadmin-hackers@arkaria.postgresql.org; Fri, 05 May 2017 15:43:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d6fNz-0006To-K4 for pgadmin-hackers@arkaria.postgresql.org; Fri, 05 May 2017 15:43:15 +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.84_2) (envelope-from ) id 1d6fNy-0006Tf-Go for pgadmin-hackers@postgresql.org; Fri, 05 May 2017 15:43:14 +0000 Received: from mail-io0-x235.google.com ([2607:f8b0:4001:c06::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1d6fNu-0004u7-EG for pgadmin-hackers@postgresql.org; Fri, 05 May 2017 15:43:13 +0000 Received: by mail-io0-x235.google.com with SMTP id p80so12510834iop.3 for ; Fri, 05 May 2017 08:43:10 -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=EIqn6av/nH4fJckv9Qkgs3fXrIW/F82E4sLfAeWMUlE=; b=X1PC+W1BDq7FX7XJ8wwnEZthUa2DrWeSR3JYMXg8J6N1dsJQSn+cd93BohZFiFjDw4 OU+C9ViM9a1gRxJnlGT/CuImdD4xl6p5OOQCcYKkKNaVGkBZedNfeYEJ1xUdYcho1Bs5 CIYlvaq8BEDeVl+wZj6J4AYKS4/JiOYeRi3ZjIENmqCmyL22yMARzYgzXNRHUbX6B8Ke Be4LLli846kh7tguz7MTPGIvhMEDXYcAXurnOCPbeHScgNQSo5ls3uWz0xRGsgvVHY8c U9JENJsLshrymp41DQ6fZFfptmUbJSJ5HeuvBszwzYmCgnSzVOVPDcdSPzQQ3J8jF9Nw d/sg== 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=EIqn6av/nH4fJckv9Qkgs3fXrIW/F82E4sLfAeWMUlE=; b=Yek5TfygXnA1o52QZIsNKPL6OH3n7q95ompvd+6vGGUrleYJnHwPhioV+1UfdF7obo E1YVCSc44RegXp4fTtzJLDmqnnQPIwuEoZ9gLXaQfteVcrFg5xiIDb3xEuElZJ58m2Eu 6vR3RwxcUzw5FIEZWcKIE35fNNFfKIRYaAtEXvrx11nWUhRIucxsymHyGxmnfIOMsijU 4erx4bcLLAAryg5XYQ+x4X4gDv+VU1I1rquDK/Lugp+vnLQqvkyR/Qkr0U8qOj1g34m7 An/sqAS3v4wFm9+Q3PxXfwhQr4OdftTts9WWSO9CXHpVvTEriMjZlXxDeCzB+CwlKknD PEvw== X-Gm-Message-State: AN3rC/6BhbVUyGYpMpHTLqPPzoEnkp6+fAdcfl9QpAqTCeFPXN02Kyxx +gM5Lyrm9NZyGNGJ/A+0OtNeQWKnYaoa X-Received: by 10.157.40.5 with SMTP id m5mr14951336otb.111.1493998989242; Fri, 05 May 2017 08:43:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.138.13 with HTTP; Fri, 5 May 2017 08:43:08 -0700 (PDT) In-Reply-To: References: From: Khushboo Vashi Date: Fri, 5 May 2017 21:13:08 +0530 Message-ID: Subject: Re: [pgAdmin4][Patch]: Fixed RM #2315 : Sorting by size is broken To: Joao Pedro De Almeida Pereira Cc: Dave Page , pgadmin-hackers , Ashesh Vashi , George Gelashvili Content-Type: multipart/alternative; boundary=001a113e1b3e0c8acd054ec8bfdc 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 --001a113e1b3e0c8acd054ec8bfdc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joao & George, On Fri, May 5, 2017 at 9:00 PM, Joao Pedro De Almeida Pereira < jdealmeidapereira@pivotal.io> wrote: > Hi Khushboo, > > We looked at your updated patch: > - the tests look good! > - there's a small comment header change needed in size_prettify_spec > ok. will change. > - it looks like the previous and new functions have different behaviors > (where the new behavior changes units on 10000 of the lower unit, a 9999G= B) > It is the same behaviour as pg_size_pretty function of PostgreSQL > - We should clarify that in size_prettify, we were mostly talking about > name readability in your first patch, and that the original structure was > better (especially the sizes array) > At first glance, the new sizePrettify appears to behave like a for loop, > so that might be the simplest refactor. > > I have followed the code structure of the pg_size_pretty function of PostgreSQL :) . Thanks, > Joao and George > > > > On Thu, May 4, 2017 at 5:02 AM, Khushboo Vashi < > khushboo.vashi@enterprisedb.com> wrote: > >> Hi, >> >> Please find the attached updated patch. >> >> Thanks, >> Khushboo >> >> On Fri, Apr 28, 2017 at 7:58 PM, Matthew Kleiman >> wrote: >> >>> Hi Khushboo, >>> >>> That sounds good. Sorry if we weren't clear at first. >>> >>> Have a good holiday weekend! >>> >>> Sarah & Matt >>> >>> >>> On Fri, Apr 28, 2017 at 4:35 AM, Khushboo Vashi < >>> khushboo.vashi@enterprisedb.com> wrote: >>> >>>> Hi Sarah, >>>> >>>> On Thu, Apr 27, 2017 at 7:38 PM, Sarah McAlear >>>> wrote: >>>> >>>>> Hi Kushboo! >>>>> >>>>> We understand your point, but we believe that relying on 2 independen= t >>>>> functions to deliver the same formatting can become a problem if the = PG >>>>> function changes. Our suggestion is to use a single function in our >>>>> javascript code to do this formatting. >>>>> >>>>> It seems reasonable to me and I am going to use a single javascript >>>> function which will support PB also (as per Dave we should add support= till >>>> PB) . >>>> >>>>> If the community believes we can live with this risk, let's move >>>>> forward. >>>>> >>>>> Thanks! >>>>> Sarah & Joao >>>>> >>>>> On Thu, Apr 27, 2017 at 1:50 AM, Khushboo Vashi < >>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>> >>>>>> Hi Joao & Sarah, >>>>>> >>>>>> On Wed, Apr 26, 2017 at 8:46 PM, Joao Pedro De Almeida Pereira < >>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>> >>>>>>> Hi Khushboo! >>>>>>> >>>>>>> Thanks for your reply! >>>>>>> >>>>>>> >>>>>>>> *SQL Files:* >>>>>>>>> >>>>>>>>> - Is there a way to avoid conditionals here? >>>>>>>>> >>>>>>>>> >>>>>>>>> - Maybe we can use the same javascript function to prettify >>>>>>>>> all the sizes >>>>>>>>> >>>>>>>>> >>>>>>>>> In case of collection node (ex: Databases), I have implemented >>>>>>>>> this functionality via putting a formatter for a back-grid column= . So, it >>>>>>>>> is applicable for the entire column not for the individual cell. = To apply >>>>>>>>> the javascript function on a single cell for the column (string c= olumn), >>>>>>>>> first we need to identify that cell and then apply the function, = I think >>>>>>>>> this is overhead. Just to avoid conditional sql template I would = not prefer >>>>>>>>> this approach. >>>>>>>> >>>>>>>> >>>>>>> We are not totally sure we understood what you meant on the previou= s >>>>>>> statement. Are you saying that the conditionals in SQL are used to = ensure >>>>>>> that we can apply a javascript function at column level instead of = cell >>>>>>> level? >>>>>>> >>>>>>> Correct. >>>>>> >>>>>>> Our concern is that the templates are being made more complex and >>>>>>> inconsistencies are introduced in the code and the UI. >>>>>>> >>>>>> >>>>>> Inconsistencies in the UI can be avoided through making the >>>>>> size_formatter same as pg_size_pretty function which I will implemen= t. >>>>>> I have checked the pg_size_pretty function code and it supports till >>>>>> TB format, so I think we should keep till TB only. >>>>>> >>>>>> In this particular example, we are allowing the backend to respond >>>>>>> sometimes with prettified data and sometimes without it, so at UI l= evel we >>>>>>> will have inconsistencies between screens or more complex Javascrip= t code >>>>>>> to support sometimes prettifying and sometimes not prettify the sam= e >>>>>>> fields. >>>>>>> >>>>>>> We have separate logic for collection and single node in >>>>>> statistics.js and we are using javascript code for prettifying only = for >>>>>> collection node. >>>>>> >>>>>> >>>>>>> What we were thinking was to maybe not specify on the SQL level and >>>>>>> have the same format for "Size" everywhere in the UI. >>>>>>> >>>>>>> >>>>>> Here our main concern is inconsistency in "Size" format in the UI >>>>>> that can be avoided as I said earlier. >>>>>> We are using pg_size_pretty function for different fields like Size, >>>>>> Index Size, Table space size, Tuple length, Size of Temporary files = in >>>>>> different modules and some of them are cell level and we don't requi= re to >>>>>> put overhead on cell level fields as sorting is not required for ind= ividual >>>>>> node statistics. >>>>>> >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> Joao & Sarah >>>>>>> >>>>>>> On Tue, Apr 25, 2017 at 11:48 PM, Khushboo Vashi < >>>>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Hi Joao & Sarah, >>>>>>>> >>>>>>>> Thanks for reviewing the patch. >>>>>>>> >>>>>>>> On Tue, Apr 25, 2017 at 8:34 PM, Joao Pedro De Almeida Pereira < >>>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>>> >>>>>>>>> Hello Khushboo, >>>>>>>>> >>>>>>>>> We reviewed the this patch and have some suggestions: >>>>>>>>> >>>>>>>>> *Python:* >>>>>>>>> =E2=80=8B >>>>>>>>> The functionality for adding the "can_prettify" is repeated in >>>>>>>>> multiple places. Maybe this could be extracted into a function. >>>>>>>>> >>>>>>>>> When I have implemented this, my first thought is exactly same as >>>>>>>> you suggested but while looking at the code I felt its not a good= idea to >>>>>>>> have a function. In case of a function, we need to pass the whole >>>>>>>> result-set as well as the list of fields which we need to be prett= ified. >>>>>>>> So, only for 2 lines, I didn't find any reason to make a function. >>>>>>>> >>>>>>>>> *Javascript:* >>>>>>>>> =E2=80=8B >>>>>>>>> >>>>>>>>> - The class Backgrid.SizeFormatter doesn't seem to have any >>>>>>>>> tests. >>>>>>>>> >>>>>>>>> >>>>>>>>> Sure, will do. >>>>>>>> >>>>>>>>> >>>>>>>>> - The function pg_size_pretty displays bytes and Kilobytes >>>>>>>>> differently. >>>>>>>>> - Is it possible to add PB as well? >>>>>>>>> >>>>>>>>> Will check and add PB. >>>>>>>> >>>>>>>>> >>>>>>>>> - >>>>>>>>> - The function is a little bit hard to read, is it possible to >>>>>>>>> refactor using private functions like: >>>>>>>>> >>>>>>>>> Will make it more readable. >>>>>>>> >>>>>>>>> fromRaw: function (rawData, model) { >>>>>>>>> var unitIdx =3D findDataUnitIndex(rawData); >>>>>>>>> if (unitIdx =3D=3D 0) { >>>>>>>>> return rawData + ' ' + this.dataUnits[i]; >>>>>>>>> } >>>>>>>>> return formatOutput(rawData, unitIdx); >>>>>>>>> }, >>>>>>>>> >>>>>>>>> =E2=80=8B >>>>>>>>> >>>>>>>>> >>>>>>>>> - In statistics.js:326 we believe it would make the code more >>>>>>>>> readable if we change the variable "c" to "rawColumn" and "col= " to "column". >>>>>>>>> >>>>>>>>> >>>>>>>>> I will change the variable name from "c" to "rawColumn" but I >>>>>>>> think "col" is appropriate as we already have columns variable and= anyone >>>>>>>> can confuse while reading the code (for columns and column). >>>>>>>> >>>>>>>>> >>>>>>>>> *SQL Files:* >>>>>>>>> =E2=80=8B >>>>>>>>> >>>>>>>>> - Is there a way to avoid conditionals here? >>>>>>>>> - Maybe we can use the same javascript function to prettify >>>>>>>>> all the sizes >>>>>>>>> >>>>>>>>> >>>>>>>>> In case of collection node (ex: Databases), I have implemented >>>>>>>> this functionality via putting a formatter for a back-grid column.= So, it >>>>>>>> is applicable for the entire column not for the individual cell. T= o apply >>>>>>>> the javascript function on a single cell for the column (string co= lumn), >>>>>>>> first we need to identify that cell and then apply the function, I= think >>>>>>>> this is overhead. Just to avoid conditional sql template I would n= ot prefer >>>>>>>> this approach. >>>>>>>> >>>>>>>>> >>>>>>>>> Visually we saw a difference between "Databases" statistics and a >>>>>>>>> specific database statistics. In "Databases" statistics the "Size= " is "7.4 >>>>>>>>> MB" but when you are in the specific database the "Size" is "7420= kB". >>>>>>>>> Is this the intended behavior? >>>>>>>>> >>>>>>>>> Only for the Databases (collection node), the client side >>>>>>>> functionality is implemented not for individual node , so this beh= aviour is >>>>>>>> different. For the individual node still, we are using pg_size_pre= tty >>>>>>>> function >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Joao & Sarah >>>>>>>>> >>>>>>>>> On Tue, Apr 25, 2017 at 7:58 AM, Dave Page >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Ashesh, can you review/commit this please? >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On Tue, Apr 25, 2017 at 10:18 AM, Khushboo Vashi < >>>>>>>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Fixed RM #2315 : Sorting by size is broken. >>>>>>>>>>> >>>>>>>>>>> Removed the pg_size_pretty function from query for the >>>>>>>>>>> collection and introduced the client side function to convert s= ize into >>>>>>>>>>> human readable format. So, the sorting issue is fixed as the al= gorithm will >>>>>>>>>>> get the actual value of size instead of formatted value. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Khushboo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Sent via pgadmin-hackers mailing list ( >>>>>>>>>>> pgadmin-hackers@postgresql.org) >>>>>>>>>>> To make changes to your subscription: >>>>>>>>>>> http://www.postgresql.org/mailpref/pgadmin-hackers >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dave Page >>>>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>>>> Twitter: @pgsnake >>>>>>>>>> >>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Thanks, >>>>>>>> Khushboo >>>>>>>> >>>>>>> >>>>>>> >>>>>> Thanks, >>>>>> Khushboo >>>>>> >>>>> >>>>> >>>> Thanks, >>>> Khushboo >>>> >>> >>> >> >> >> -- >> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgadmin-hackers >> >> > --001a113e1b3e0c8acd054ec8bfdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joao & George,


On Fri, May 5, 2017 at 9:00 PM, Joao Pe= dro De Almeida Pereira <jdealmeidapereira@pivotal.io> wrote:
Hi Khushboo,

We looked at your updated patch:
- the tests look good!
- there's a small comment= header change needed in size_prettify_spec
ok= . will change.=C2=A0
- it looks like the previous and new functions have = different behaviors (where the new behavior changes units on 10000 of the l= ower unit, a 9999GB)=C2=A0
It is the same beha= viour as pg_size_pretty function of PostgreSQL
- We should clarify that i= n size_prettify, we were mostly talking about name readability in your firs= t patch, and that the original structure was better (especially the sizes a= rray)
At first glance, the new sizePrettify appears to behave like a for= loop, so that might be the simplest refactor.

I have followed the code structure of the pg_size_pretty fu= nction of PostgreSQL :) .

Thanks,
Joa= o and George
=C2=A0


On Thu, May 4, 2017 at 5:02 AM, K= hushboo Vashi <khushboo.vashi@enterprisedb.com><= /span> wrote:
Hi,

Please find the attached updated patch.

Thanks,
Khushboo

On Fri, Apr 2= 8, 2017 at 7:58 PM, Matthew Kleiman <mkleiman@pivotal.io> = wrote:
Hi Khushboo,

That sounds good. Sorry if we weren't= clear at first.=C2=A0

Have a good holiday weekend= !

Sarah & Matt


<= /div>
On Fri, Ap= r 28, 2017 at 4:35 AM, Khushboo Vashi <khushboo.vashi@enterp= risedb.com> wrote:
Hi Sarah,
On Thu, Apr 27, 2017 at 7:38 PM, Sarah M= cAlear <smcalear@pivotal.io> wrote:
Hi Kushboo!

We understand your point, but we believe that relying on 2 independen= t functions to deliver the same formatting can become a problem if the PG f= unction changes. Our suggestion is to use a single function in our javascri= pt code to do this formatting.=C2=A0

It seems reasonable to me and I am going to use a single javas= cript function which will support PB also (as per Dave we should add suppor= t till PB) .
If the community believes we ca= n live with this risk, let's move forward.

Thanks!
Sarah & Joao

=
On Thu, Apr 27, 2017 at 1:50 AM, Khushboo Vashi = <khushboo.vashi@enterprisedb.com> wrote:<= br>
Hi Joao & Sarah,
=
On Wed, Apr 26, 2017 at 8:46 PM, Joao = Pedro De Almeida Pereira <jdealmeidapereira@pivotal.io><= /span> wrote:
Hi Khushboo!

Thanks for your reply!
=C2=A0
SQL Files:
  • Is there a = way to avoid conditionals here?=C2=A0
  • Maybe we can use the same javascript function to prettify all the si= zes

In case of collection node (ex: Databases), I have impleme= nted this functionality via putting a formatter for a back-grid column. So,= it is applicable for the entire column not for the individual cell. To app= ly the javascript function on a single cell for the column (string column),= first we need to identify that cell and then apply the function, I think t= his is overhead. Just to avoid conditional sql template I would not prefer = this approach.

We are not totally sure we understood what you meant on the previ= ous statement. Are you saying that the conditionals in SQL are used to ensu= re that we can apply a javascript function at column level instead of cell = level?=C2=A0

Corr= ect.=C2=A0
Our concern is that the templates are being made more co= mplex and inconsistencies are introduced in the code and the UI.
=C2=A0
Inconsistencies in the UI= can be avoided through making the size_formatter same as pg_size_pretty fu= nction which I will implement.
I have checked the pg_size_pre= tty function code and it supports till TB format, so I think we should keep= till TB only.

In this particular example, we are allowing the = backend to respond sometimes with prettified data and sometimes without it,= so at UI level we will have inconsistencies between screens or more comple= x Javascript code to support sometimes prettifying and sometimes not pretti= fy the same fields.=C2=A0

We have separate logic for collection and single node in statistic= s.js and we are using javascript code for prettifying only for collection n= ode.
=C2=A0
What we were thinking was to maybe not specif= y on the SQL level and have the same format for "Size" everywhere= in the UI.=C2=A0
=C2=A0
Here our main concern is inconsistency in "Size" format in the= UI that can be avoided as I said earlier.
We are using pg_size_p= retty function for different fields like Size, Index Size, Table space size= , Tuple length, Size of Temporary files in different modules and some of th= em are cell level and we don't require to put overhead on cell level fi= elds as sorting is not required for individual node statistics.
<= div class=3D"gmail-m_8902354621202749941m_3534569346842034918m_-85673381455= 36162555m_4403425612319584267m_-6516206247763375092h5">
=C2=A0
=C2=A0
= Thanks
Joao & Sarah
<= div class=3D"gmail_extra">
On Tue, Apr 25, 20= 17 at 11:48 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.= com> wrote:
Hi Joao & Sarah,

Thanks = for reviewing the patch.

On Tue, Apr 25, 2017 at 8:34 PM, Joao Pedro De Almeida P= ereira <jdealmeidapereira@pivotal.io> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Hello Khu= shboo,

We reviewed the this patch and have some suggesti= ons:

Python:

=E2=80=8B
The functionality for adding the "can= _prettify" is repeated in multiple places. Maybe this could be extract= ed into a function.=C2=A0

When I have implemented this, my first thought is exactly same as you sug= gested but =C2=A0while looking at the code I felt its not a good idea to ha= ve a function. In case of a function, we need to pass the whole result-set = as well as the list of fields which we need to be prettified. So, only for = 2 lines, I didn't find any reason to make a function.

Javascri= pt:

=E2=80=8B
  • The class=C2=A0Backgrid.SizeForm= atter doesn't seem to have any tests.=C2=A0
    =

Sure, will do= .=C2=A0
  • The function pg_size_pretty displays byt= es and Kilobytes differently.=C2=A0
  • Is it possible to add PB as= well?
Will check and add= PB.=C2=A0
  • The function is a little bit hard to re= ad, is it possible to refactor using private functions like:
Will make it more readable.
fromRaw: function (rawData, model) {
   var unitIdx =3D findDataUnitIndex(rawData);
   if (unitIdx =3D=3D 0) {
      return rawData + ' ' + this.dataUnits[i];
   }
   return formatOutput(rawData, unitIdx);
},
=E2=80=8B=

  • In statistics.js:326 we believe it would= make the code more readable if we change the variable "c" to &qu= ot;rawColumn" and "col" to "column".
=

I will change the varia= ble name from =C2=A0"c" to =C2=A0"rawColumn" but I thin= k "col" is appropriate as we already have columns variable and an= yone can confuse while reading the code (for columns and column).
<= /div>

SQL Files:

=E2=80=8B
  • Is there a way to avoid condit= ionals here?=C2=A0
  • Maybe we can use the same javascript function to= prettify all the sizes

In case of collection node (ex: Databases), I have implemented th= is functionality via putting a formatter for a back-grid column. So, it is = applicable for the entire column not for the individual cell. To apply the = javascript function on a single cell for the column (string column), first = we need to identify that cell and then apply the function, I think this is = overhead. Just to avoid conditional sql template I would not prefer this ap= proach.

Visually we saw a difference= between "Databases" statistics and a specific database statistic= s. In "Databases" statistics the "Size" is "7.4 MB= " but when you are in the specific database the "Size" is &q= uot;7420 kB".
Is this the intended behavior?

Only for the Databases (collectio= n node), the client side functionality is implemented not for individual no= de , so this behaviour is different. For the individual node still, we are = using pg_size_pretty function
=C2=A0

Thanks
Joao & Sarah
<= br>
On Tue, Apr 25, 2017 at 7:58 AM, Dave Page <= dpage@pgadmin.org> wrote:
Ashesh, can you review/commit this pleas= e?

Thanks.

On Tue, Apr 25, 2017 at 10:18 AM, Khushboo= Vashi <khushboo.vashi@enterprisedb.com> = wrote:
Hi,

Fixed RM #2315 : Sorting by s= ize is broken.

Removed the pg_size_pretty function= from query for the collection and introduced the client side function to c= onvert size into human readable format. So, the sorting issue is fixed as t= he algorithm will get the actual value of size instead of formatted value.= =C2=A0
=C2=A0

Thanks,
Khus= hboo




--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-ha= ckers


<= br clear=3D"all">

--
http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseD= B UK: http://www.= enterprisedb.com
The Enterprise PostgreSQL Company


= Thanks,
Khushboo


Thanks,
Khushboo


Thanks,
Khushboo




--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-ha= ckers



--001a113e1b3e0c8acd054ec8bfdc--