Thread: Idea: check SQL before copying to SQL dialogue.
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 occasionsthe 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 forgetto 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 majorpitfall for me. Any +1's on this? Regards Erwin
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. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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 :) -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
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. 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 wantthe outdated version. I do sometimes. -- Erwin Brandstetter
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
On 20.07.2011 22:45, Guillaume Lelarge wrote: > 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 versionat 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 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. But this is really only a minor point. 1.) Check for updates and make the user aware of them - if any. 2.) Let him chose what to copy to the SQL editor. 3.) Update the object browser while being at it - depending on OR regardless of his pick. I would go with the user's choice. After a refresh, old information is gone. If it is substantially easier to refresh objects in question right away, then I can live with that, too. As long as the usercan get the old version in the SQL editor. -- Erwin Brandstetter