Re: Selecting tables from Browser

On Tue, Aug 22, 2017 at 8:27 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Tue, Aug 22, 2017 at 12:17 AM, Shirley Wang <swang(at)pivotal(dot)io> wrote:
>
>> Hi Rob
>> On Mon, Aug 21, 2017 at 1:53 PM Robert Eckhardt <reckhardt(at)pivotal(dot)io>
>> wrote:
>>
>>> Shirley,
>>>
>>> I have a few questions.
>>>
>>> 1. Why 20. It is a dunbar number and seems smallish but is there
>>> another reason?
>>>
>>> The browser fits about 30 ish items right now on my smallish laptop
>> screen. The question we asked ourselves is 'what is the most content we can
>> show before the browser gets unwieldy?'
>>
>
> A lot more than the proposed 20. I regularly work with ~100 tables in a
> single schema, and having to go through an additional dialogue to find what
> I need would be hugely inconvenient.
>
> I will often learn about a new database by browsing through it as well,
> jumping from table to table as I discover relationships etc. I couldn't
> imagine doing that with a filtering dialogue getting in the way.
>

Would you be able to describe more about your use case? What role are you
taking on as you are browsing through the database, what are you trying to
accomplish and why?

>
>
>>
>> You have thoughts on this?
>>
>>
>>>
>>> 1. Since this is referred to as an Object Manager I assume the same
>>> thing will eventually be available for databases, schema, partitions, etc.
>>> How do permissions work currently to limit m view of these objects? (or do
>>> they)
>>>
>>>
>> Good point about the name implying further reach than just tables. We're
>> going to change the dialog header to show 'Select tables for display', at
>> least until we decide we want to include databases, schema, partitions.
>>
>> I'm not sure how permissions works to limit the view, our assumption is
>> that permissions does though.
>>
>> Dave P do you have more insight on what permissions can limit?
>>
>
> Permissions don't limit what you would see here. They limit a roles
> ability to insert/update/delete data in tables, but not to examine the
> schema.
>

So as a Platform Administrator (which we're defining as someone in a very
large company who works with many DBAs across multiple databases), I am not
able to restrict what schemas different user groups can see?

More specifically, if there are 500 schemas for an org, every user will be
able to see them all in the browser and changing permissions will not
impact what a DBA will see?

>
>
>>
>>> 1. Do you think that this would look differently if you assumptions
>>> were based on a user who writes BI reports or some other non-DBA user?
>>>
>>> Potentially, as you mentioned off the email thread, a DBA would be
>> interested in a larger list of tables than someone who writes BI reports.
>>
>> That said, since this is a problem we hear from DBAs, and they feel the
>> most pain around this, I think it's fine to focus on solving the problem
>> for them. Solving their pains will also address the pains of people who
>> write BI reports since they also feel the same issues at a lesser intensity
>>
>> We will be testing with non-DBA users though too.
>>
>
> I think this is the wrong way to approach this problem. At the very least,
> the limit of 20 objects needs to have a much higher value, and be
> configurable.
>
> I think it would be far better to implement searching of the tree as we
> had in pgAdmin 3 (and a number of users have requested we re-implement),
>

Implementing search will definitely add value for users, we've also heard
the same requests from people during our interviews as well. However it
doesn't solve for navigating the browser when there are enough tables to
crash or significantly slow down the application.

20 objects is where we're starting from, it's definitely a risky assumption
we're making and I'm not convinced it's the right number. But for user
interviews its good to have a clear point of view on a design decision so
we can test it and get feedback on it.

> and do partial branch loading on the tree, where we display maybe 30
> items, then add a "Load more..." node at the end, that when click would be
> replaced with the next 30 items.
>

I think that would make it difficult to get to zebra table. A partial load
could be a solution, followed by some way to navigate to the tables towards
the end of the alphabet.