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.
|
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: