Re: [pgadmin-hackers] [Design Update][History] - Mailing list pgadmin-hackers

Hello all,

Here are the updated designs for history. Goal is to display the same information currently in pgAdmin, just rearranged to enable people to view the full query. We found that when using pgAdmin, people use the query editor as a place to store their queries, and use history to view previous iterations of that query.

Change from previous iteration is the addition of a vertically draggable messages box, which would display a truncated version of the original message displayed in the messages tab. This does not impact messages from queries currently run, info/functionality from those tabs will remain the same.

As always, feedback appreciated :)

Shirley

On Tue, Mar 7, 2017 at 4:26 PM Dave Page <dpage@pgadmin.org> wrote:

On Tue, Mar 7, 2017 at 8:07 PM, Shirley Wang <swang@pivotal.io> wrote:
>
>
> On Tue, Mar 7, 2017 at 4:01 AM Dave Page <dpage@pgadmin.org> wrote:
>>
>> On Mon, Mar 6, 2017 at 9:19 PM, Shirley Wang <swang@pivotal.io> wrote:
>>>
>>> Thanks, Dave
>>>
>>>>
>>>> I disagree. I use both the Explain and Messages tabs all the time, and
>>>> rarely the History tab. You cannot easily merge the data output and EXPLAIN
>>>> tabs because they show complementary information.
>>>
>>>
>>> I see. It may be that we haven't heard about the full value of the
>>> Explain tab (it also doesn't seem to be working on my version of pgAdmin
>>> (w/Postgres, not Greenplum)). I see no problem with keeping it as is until
>>> we learn more.
>>>
>>> Here are the updated versions of History (Explain isn't included because
>>> we were working with the assumption that the tab could be combined with
>>> results, we can add it again unless we learn something new).
>>>
>>> - Users are able to click or use the arrow keys on their keyboard to
>>> navigate through the queries on the left.
>>> - List of queries is expandable
>>> - Copy all is fixed to the top right corner so it'll be present as users
>>> vertically/horizontally scroll
>>
>>
>> That makes it impossible any details from the initial grid view.
>>
>>
>>>
>>>
>>>
>>> To your points,
>>>
>>>>
>>>> The Messages tab is used to quickly show the full set of messages from
>>>> the last executed query. Having that info only on the results tab is less
>>>> useful for a number of reasons:
>>>>
>>>> - It shows the results from all queries, thus making the display more
>>>> cluttered when you're only interested in the results of the last query
>>>> (which is probably the majority of the time).
>>>>
>>> In the messages tab, it seems like when the query ran successfully, the
>>> message shows number of rows affected and total time, both which are shown
>>> with your query history. It also seems like when there is an error message,
>>> it duplicates the description and splits out line and character. We can
>>> condense that into 3 groups of info : error code, a description, and
>>> location within the query where the error was detected.
>>
>>
>> It'll also show (in the correct order) any notices or other messages
>> raised by stored functions. It's critical that these remain easy to read as
>> they're used for debugging as well as conveying non-result info to the user.
>>
>>>
>>>
>>> Immediate feedback on any errors should be displayed right after you run
>>> the query. It appears there's already a pattern for feedback w/ the green
>>> box that appears in the bottom right corner when you run a successful query.
>>> Any sort of feedback on the query run (success/fail messages) should be
>>> treated consistently. Persistent messages can live within the history.
>>>
>>>>
>>>> - It shows information above and beyond the messages, again, cluttering
>>>> the display and detracting from the message info.
>>>
>>>
>>> You're right that the error messages displays information at a higher
>>> level than query history, which can be solved by establishing hierarchy -
>>> error messages go at the top.
>>
>>
>> No, error messages need to be shown properly ordered amongst any other
>> messages. The output is intentionally sequential - if it weren't, it would
>> be useless for debugging.
>
>
> I see. We're looking into messages for storage procedures now and how that
> should be solved. Are there other types of messages we should be aware of?

No, I don't think so. They come through the standard postgres elog
mechanism which should cover other sources as well.


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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company