Re: [pgAdmin4][Patch]: RM #2849 - Allow editing of data on tables with OIDs but no primary key

From: Khushboo Vashi <khushboo(dot)vashi(at)enterprisedb(dot)com>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: [pgAdmin4][Patch]: RM #2849 - Allow editing of data on tables with OIDs but no primary key
Date: 2017-12-06 09:04:06
Message-ID: CAFOhELf1okJuvG+_SKQB8uKifeh-MsQ2Ee2b7XAipBtX5MrmGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi Dave,

On Tue, Dec 5, 2017 at 9:43 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> On Mon, Dec 4, 2017 at 4:01 PM, Khushboo Vashi <
> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>
>>
>>
>> On Sat, Dec 2, 2017 at 10:42 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>> On Thursday, November 30, 2017, Khushboo Vashi <
>>> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find the attached updated patch.
>>>>
>>>> On Mon, Nov 27, 2017 at 5:15 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Thu, Nov 23, 2017 at 1:28 PM, Khushboo Vashi <
>>>>> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please find the attached patch for RM #2849: Allow editing of data on
>>>>>> tables with OIDs but no primary key.
>>>>>>
>>>>>
>>>>> I like that if I add a new row or rows and hit Save, the OIDs are
>>>>> fetched immediately. However;
>>>>>
>>>>> - It marks the row as read-only. We do that currently because we don't
>>>>> return the key info on Save, and thus require a Refresh before any further
>>>>> editing. However, if we have the OID, we can edit again immediately.
>>>>>
>>>>> Fixed
>>>>
>>>>> - If we can return the new OIDs on Save, can't we do the same for
>>>>> primary key values? That would be consistent with OIDs, and would remove
>>>>> the need to disable rows, leading to a much nicer use experience I think.
>>>>>
>>>>> Implemented
>>>>
>>>
>>> This looks great, however there is one small issue I spotted; it looks
>>> like we're inserting rows in a random order. For example, in the screenshot
>>> attached, the last 5 rows were added in the order seen in the key1 column,
>>> and then I hit Save and got the id values returned. Is that caused by
>>> something we're doing, or the database server?
>>>
>>> The root cause of the issue is, Python dictionary does not preserve the
>> order. To fix this issue I have manually sorted the added rows index and
>> stored it into OrderedDict.
>> Please find the attached updated patch.
>>
>
> Thanks Khushboo. My apologies, but I found something else when testing.
> Instead of just returning and updating the values for the key columns, we
> should do it for all columns. This would have 2 benefits (and I suspect,
> might actually make the code a little more simple):
>
> Done

> 1) We'd see the values for columns with default values.
>
> 2) We'd see the formatted values for other columns - e.g. with a JSONB
> column, you'll immediately see what the re-generated JSON looks like.
>
> I assume it's straightforward to update all columns rather than just the
> key columns?
>
The approach is same. Before I was just updating the primary keys/oids, now
I update all the columns of a row.

Please find the attached updated patch.

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

Thanks,
Khushboo

Attachment Content-Type Size
RM_2849_ver3.patch text/x-patch 22.2 KB

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Khushboo Vashi 2017-12-06 09:27:14 Re: [pgAdmin4][Patch]: RM #2849 - Allow editing of data on tables with OIDs but no primary key
Previous Message Khushboo Vashi 2017-12-06 05:45:05 [pgAdmin4][Patch]: Fixed RM #2779 - Lost field size