Re: [Design Update][History]

I like it. My only comment is that the the messages section should honour
line breaks, and should use a fixed-width font as it may include error
indicators or output from loops which may (effectively) be tabulated.

On Wed, Mar 15, 2017 at 8:48 PM, Shirley Wang <swang(at)pivotal(dot)io> wrote:

> 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.
>
>
>
>
> [image: 01 Query HIstory.png]
> [image: 02 Query HIstory.png]
> [image: 03 Query History Error.png]
> [image: 04 Query History Error.png]
>
> As always, feedback appreciated :)
>
> Shirley
>
> On Tue, Mar 7, 2017 at 4:26 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
> On Tue, Mar 7, 2017 at 8:07 PM, Shirley Wang <swang(at)pivotal(dot)io> wrote:
> >
> >
> > On Tue, Mar 7, 2017 at 4:01 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
> >>
> >> On Mon, Mar 6, 2017 at 9:19 PM, Shirley Wang <swang(at)pivotal(dot)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
>
>

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

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