Re: Idea: check SQL before copying to SQL dialogue. - Mailing list pgadmin-hackers

From Guillaume Lelarge
Subject Re: Idea: check SQL before copying to SQL dialogue.
Date
Msg-id 1311194743.2057.29.camel@laptop
Whole thread Raw
In response to Re: Idea: check SQL before copying to SQL dialogue.  (Erwin Brandstetter <brandstetter@falter.at>)
Responses Re: Idea: check SQL before copying to SQL dialogue.  (Erwin Brandstetter <brandstetter@falter.at>)
List pgadmin-hackers
On Wed, 2011-07-20 at 21:41 +0200, Erwin Brandstetter wrote:
> On 20.07.2011 20:26, Guillaume Lelarge wrote:
> > On Wed, 2011-07-20 at 19:05 +0100, Dave Page wrote:
> >> On Wed, Jul 20, 2011 at 6:05 PM, Erwin Brandstetter
> >> <brandstetter@falter.at>  wrote:
> >>> Aloha!
> >>>
> >>> A lot of work has been put into when and where to refresh the browser
> >>> window.
> >>>
> >>>  From my experience it is often a _good_ thing, that changes via SQL are not
> >>> reflected in the browser window immediately. Serves me well as a poor man's
> >>> undo-tool.
> >>> On the other hand, one tends to forget about refreshing the browser,
> >>> especially casual users who are not aware on what occasions the browser's
> >>> display is refreshed automatically.
> >>> The major pitfall is with the option "Copy SQL from main form to SQL
> >>> dialogue" - and most people use that one. If you forget to refresh
> >>> beforehand, you may lose your most recent changes and may not even notice
> >>> it.
> >>> Keeps happening to me.
> >>>
> >>> How about this idea?
> >>> - Whenever the "Copy SQL from main form to SQL dialogue" feature kicks in,
> >>> check if the displayed SQL is the latest version.
> >>> - If not, ask the user whether he wants the latest instead. (DO ask!)
> >>> (We already have a similar check befor saving anything from a properties
> >>> dialog.)
> >>>
> >>> Anybody trying hard enough can still screw up, with copy / paste, for
> >>> instance. But this idea would take care of the major pitfall for me.
> >>>
> >>> Any +1's on this?
> >> To do that we'd probably need a mechanism for doing quick refreshes at
> >> any point - this is something we discussed at Char(11), but will
> >> require fairly significant effort. The hope is to work on it for 1.16.
> >>
> > Well, as we said, the main issue is: should we only refresh the object
> > you clicked on, or all the objects under it? I mean: if I click on a
> > schema, should it refresh only the schema's properties and sql pane? or
> > should it refresh the schema's properties, sql pane and the same for
> > every objects belonging to the schema? On a schema, I would understand
> > we only refresh the schema itself and not its objects, because the SQL
> > pane won't differ. But take a table for example. If we don't refresh the
> > subobjects (columns, indexes, contraints, rules, triggers), the SQL pane
> > will be wrong.
> >
> > So, to me, the two main reasons I'm not working on it is:
> > 1. I don't have an answer to this question
> > 2. I don't have time :)
>
> I am thinking simple: only check if the SQL pane at hand (the actual text that is copied) reflects the latest version
atthe time it is copied to the  
> SQL editor. No additional checks.

Meaning we have to refresh the object properties (and all the sub-items
of a table if the object is a table).

> If the status quo has changed and the user chooses to work with the latest version, then that's what he gets in the
SQLeditor. 
> I am not even convinced we should refresh the SQL pane at this point. That's not what the user asked for - he may
stillwant the outdated version. I  
> do sometimes.
>

Well, if we have the informations, it would be stupid to loose them.


--
Guillaume
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com


pgadmin-hackers by date:

Previous
From: Erwin Brandstetter
Date:
Subject: Re: Idea: check SQL before copying to SQL dialogue.
Next
From: Vladimir Kokovic
Date:
Subject: Copy/Paste table(s) functions - git context patch