Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4

From: Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Harshal Dhumal <harshal(dot)dhumal(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>, Robert Eckhardt <reckhardt(at)pivotal(dot)io>, Shirley Wang <swang(at)pivotal(dot)io>, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>
Subject: Re: [pgadmin-hackers] Declarative partitioning in pgAdmin4
Date: 2017-06-25 13:22:51
Message-ID: CANxoLDdrzBZG8urt05qXDW06vVxaxdoWxszMp0S6Ymu3zcFmbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi All

I have implemented test cases for partitioned table. Attached is the patch
file. Please review it and if it looks good then please commit it.

On Fri, Jun 23, 2017 at 8:54 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Thanks - Ashesh, can you review/commit this please? Additional reviews
> welcome as well of course.
>
> On Fri, Jun 23, 2017 at 2:25 PM, Harshal Dhumal <
> harshal(dot)dhumal(at)enterprisedb(dot)com> wrote:
>
>> Hi,
>>
>> Please find attached patch for partition support.
>>
>> This patch includes all the work done by Akashy and support for child
>> nodes (constraints, rules, index, triggers and partition itself ) under
>> partition node.
>>
>>
>> Thanks,
>>
>> --
>> *Harshal Dhumal*
>> *Sr. Software Engineer*
>>
>> EnterpriseDB India: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>> On Tue, Jun 20, 2017 at 12:16 AM, Shirley Wang <swang(at)pivotal(dot)io> wrote:
>>
>>>
>>>
>>> On Mon, Jun 19, 2017 at 1:59 AM Akshay Joshi <
>>> akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>>>
>>>> On Fri, Jun 16, 2017 at 11:16 PM, Shirley Wang <swang(at)pivotal(dot)io>
>>>> wrote:
>>>>
>>>>> Looks good. I noticed people clicking back and forth to the columns
>>>>> tab to remember which columns they've created while filling out the
>>>>> Expressions column. It might be better to have a list of the columns and
>>>>> the datatype above the 'Partition Keys' subnode and have columns as a type
>>>>> field rather than a drop down.
>>>>>
>>>>
>>>> I think we should not duplicate that data as we already have all the
>>>> information on "Columns" tab and by providing drop down user can select
>>>> columns from there only.
>>>>
>>>>>
>>>>> Also, I think the fields someone sees after selecting the Key type
>>>>> needs to depend on what they select. Seeing both Column and Expressions
>>>>> type field might lead someone to think they need to fill out both fields.
>>>>>
>>>>
>>>> We can't, because user can select one column and provide an
>>>> expression as partition key in this case we will have to show both the
>>>> columns in subnode control. Anyways when user select columns I have
>>>> disabled the expression cell and if user selects expression column cell is
>>>> disabled.
>>>>
>>>
>>> Ah I see what you mean. What I meant was that the column would change
>>> depending on if someone selects Column or Expressions from the dropdown
>>> [image: expression.png]
>>> Can a user select more than one key type? The use case I can see where
>>> hiding 'Columns' or 'Expressions' would fail is if someone can create an
>>> expression key type and a column key type.
>>>
>>> Disabling a feature is one way to guide user behavior, but it doesn't
>>> provide enough context for someone to understand why it's disabled. It's
>>> better to only display what is absolutely necessary and hide fields that
>>> are unrelated to the workflow.
>>>
>>> Typically, disabling a UI element is useful when that disabled UI
>>> element also provides some context or value while disabled. In this case,
>>> I'm not sure it is.
>>>
>>> If hiding options isn't possible, providing some text in the fields
>>> (like N/A or --) would be helpful.
>>>
>>>
>>>
>>>>
>>>>> [image: coluns_partitioning.png]
>>>>> When is the 'In' column in the Partitions subnode enabled?
>>>>>
>>>>
>>>> In case of 'List' Partition.
>>>>
>>>
>>> It would improve the experience if the 'In' column was removed when a
>>> user selects 'Range' partitions then. And then if a user is creating a
>>> 'List' partition, 'From/To' should be hidden. In this case, 'From/To' and
>>> 'In' are dependent on that first drop down step, so seeing 'In' while on
>>> 'Range partitions' (and 'From/To' on 'List partitions') is not providing
>>> any value.
>>>
>>>
>>>>
>>>>> For the NoteControl on the bottom, what do 'Mode Control' or 'Attach
>>>>> Mode' refer to? And how can I tell the difference between 'Create Mode' and
>>>>> 'Edit Mode'?
>>>>>
>>>>
>>>> 'Mode control' is a switch control in subnode control that should be
>>>> "Mode switch control". 'Create Mode' is when user creates the new table by
>>>> clicking create-> table and 'Edit Mode' is when user open the properties
>>>> dialog for the existing table. In case of 'Edit Mode' there are two ways
>>>> user can create/attach partitions. In Attach mode we will identify and list
>>>> down the suitable tables to be attached.
>>>>
>>>
>>> I see. Describing these various states is great in case a user needs it.
>>> What are your thoughts on having it live in the documentation of pgAdmin4
>>> rather than in the dialog? This seems to be the established pattern for all
>>> other explanations.
>>>
>>>>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

--
*Akshay Joshi*
*Principal Software Engineer *

*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*

Attachment Content-Type Size
Partition_Test_Case.patch application/octet-stream 18.2 KB

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message pgAdmin 4 Jenkins 2017-06-25 14:00:34 Build failed in Jenkins: pgadmin4-master-python27-feature #7
Previous Message Dave Page 2017-06-25 13:02:11 Re: [pgAdmin4][Patch][RM_2191] : Add support for the hostaddr connection parameter