Skip site navigation (1) Skip section navigation (2)

Re: Idea: check SQL before copying to SQL dialogue.

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Erwin Brandstetter <brandstetter(at)falter(dot)at>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Idea: check SQL before copying to SQL dialogue.
Date: 2011-07-20 20:45:43
Message-ID: 1311194743.2057.29.camel@laptop (view raw or flat)
Thread:
Lists: 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(at)falter(dot)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 at the 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 SQL editor.
> I am not even convinced we should refresh the SQL pane at this point. That's not what the user asked for - he may still want 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


In response to

Responses

pgadmin-hackers by date

Next:From: Vladimir KokovicDate: 2011-07-21 03:19:03
Subject: Copy/Paste table(s) functions - git context patch
Previous:From: Erwin BrandstetterDate: 2011-07-20 19:41:05
Subject: Re: Idea: check SQL before copying to SQL dialogue.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group