Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d8jwP-0006Gi-U7 for pgadmin-hackers@arkaria.postgresql.org; Thu, 11 May 2017 08:59:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d8jwO-0002KI-Gy for pgadmin-hackers@arkaria.postgresql.org; Thu, 11 May 2017 08:59:20 +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 1d8jw9-0001vC-UD for pgadmin-hackers@postgresql.org; Thu, 11 May 2017 08:59:06 +0000 Received: from mail-io0-x236.google.com ([2607:f8b0:4001:c06::236]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1d8jw0-0005wu-5Z for pgadmin-hackers@postgresql.org; Thu, 11 May 2017 08:59:04 +0000 Received: by mail-io0-x236.google.com with SMTP id k91so17246328ioi.1 for ; Thu, 11 May 2017 01:58:55 -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=gSRQetMzt1pqTn0/PkWfAn5v/6I34333jypRNgsPcR0=; b=TfQX6oBcUpHvUjm2zYnPS6OKd0hHM8/nQucXaCExCxOHw1bE+TCe1aR/tcAE8NGE4C OEtCHX3uybIsEkU+vZ3giSZz5xaK7wdFtBE2LdF2pZBD04aBsWf82D6MKoC8brpV6lpV wsQkibnOOtPYWkVKlrZJEzBBG3Un/4MLq6MafTmeKh0Yto+HJvbyoro/yG5CVATqR37q Nw36b6szUPr4meiQTAjjzfpz6n4xuUvi9uVj2njQ0PCydpadR0G6AYJAXNgIAEQ5tFhA 7QZQrtRfCCfb9AkM5GeCRr63Ke/BAAu7hV6+ZKtqRh92P80BzGQlNHW6dA/useuQhzZt cnow== 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=gSRQetMzt1pqTn0/PkWfAn5v/6I34333jypRNgsPcR0=; b=q+9lvl/2LiJT9Y7bXDKSNOLh3xEJPOdGV0Vt+wGn8t+2CmNLEoIxcE8pS49cyF0Iud 51g+jwR+61jFjP4ir7UrGQUJYjh4NF/VW+poylvPZcwNesoOvwZjpNsCFxDLH/ALUu/f aXfK17/4vsWsQrNECA4YhGf/VAkG6639Wf5NMFqEcZ7rT9nRhJwAegum6dPi3G1Ww/eO fCkSgRip/4F7De9XX/dtlt3a9aNJggAnbhDf1rffKx4AGwvaGChueuErDcCajoMPaG0G hqT5gAxKl9nFx9jGxcgT020hr/gwmJvxYlxFjBFCzw5OtDaou4LfdrSzJq++dmpK8Go8 NI8A== X-Gm-Message-State: AODbwcCLO4F4mZZCcPLbZRkV3IvGQPdvrHeV2ODT6ZXPN2YSknt0ce1z j8ariGCkbfwVZJ3esdBInKWfdc5pGw== X-Received: by 10.107.3.165 with SMTP id e37mr7545633ioi.232.1494493133130; Thu, 11 May 2017 01:58:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.174.167 with HTTP; Thu, 11 May 2017 01:58:52 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Thu, 11 May 2017 09:58:52 +0100 Message-ID: Subject: Re: [pgAdmin4][Patch][RM2257]: Query tool - Insert row doesn't use default values To: Surinder Kumar Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary=001a113ed3be51ed60054f3bccda 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 --001a113ed3be51ed60054f3bccda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi There seems to be couple of bugs in this; - When creating a new row with my test table, if I click in the id column, don't change anything, then click in another column, the ID column value changes from [default] to [null], making it impossible to save that row with the default value. In this case I would expect it to stay at [default] unless I explicitly entered a value. - When I add a new row, but leave the id as [default], the row is saved, but the [default] marker changes from gray to black (but only in the id column. - I'm able to edit a freshly added row immediately after saving but before refreshing. This shouldn't be allowed if we don't know what the primary key value is, as it leads to failed updates such as: On Wed, May 10, 2017 at 9:52 AM, Surinder Kumar < surinder.kumar@enterprisedb.com> wrote: > Hi Dave, > > Please find attached patch for RM only. > > *Changes:* > > - All formatters now handles both [null] and [default] values > > - the cell values are validated on server side as in pgAdmin3. > > - added light grey color for cells with [null] and [default] placeholder= s. > > On Wed, May 10, 2017 at 2:12 PM, Dave Page wrote: > >> >> >> On Wed, May 10, 2017 at 9:39 AM, Surinder Kumar < >> surinder.kumar@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> On Wed, May 10, 2017 at 2:06 PM, Dave Page wrote: >>> >>>> Any chance we can get this wrapped up today Surinder? >>>> >>> =E2=80=8BI have fixed RM case, I am currently writing its feature test = cases >>> which is taking some time. >>> Should I send patch for RM case only?=E2=80=8B I will try to complete t= est cases >>> by today eod. >>> >> >> Yes please. >> >> Thanks! >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > > --=20 Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --001a113ed3be51ed60054f3bccda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

There seems to be couple of bugs in = this;=C2=A0

- When creating a new row with my test= table, if I click in the id column, don't change anything, then click = in another column, the ID column value changes from [default] to [null], ma= king it impossible to save that row with the default value. In this case I = would expect it to stay at [default] unless I explicitly entered a value.

- When I add a new row, but leave the id as [defaul= t], the row is saved, but the [default] marker changes from gray to black (= but only in the id column.

- I'm able to edit = a freshly added row immediately after saving but before refreshing. This sh= ouldn't be allowed if we don't know what the primary key value is, = as it leads to failed updates such as:


On Wed, May 10, 2017 at 9:5= 2 AM, Surinder Kumar <surinder.kumar@enterprisedb.com>= ; wrote:
Hi Dave,

Please find attached patch for RM only.

Changes:
<= div class=3D"gmail_default" style=3D"font-size:small">
=C2=A0- All formatters now=C2=A0handles both [null] and = [default] values

=C2=A0- the cell values are valida= ted on server side as in pgAdmin3.

=C2=A0- added light grey color for cells with [null] and [defaul= t] placeholders.

On Wed, May 10, 2017 at = 2:12 PM, Dave Page <dpage@pgadmin.org> wrote:


On Wed, May 10, 2017 at 9:39 AM, Surinder Kum= ar <surinder.kumar@enterprisedb.com> wrot= e:
Hi Dave,

On Wed, May 10, 2017 at 2:06 PM, Dave Page <dpag= e@pgadmin.org> wrote:
Any chance we can get this wrapped up today Surinder?
=E2=80=8BI have fixed RM cas= e, I am currently writing its feature test cases which is taking some time.=
Should I send patch for RM case only?= =E2=80=8B I will try to complete test cases by today eod.

Yes please.

Thanks!

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




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

EnterpriseDB UK: http://www.enterprised= b.com
The Enterprise PostgreSQL Company
--001a113ed3be51ed60054f3bccda--