Lists: | pgadmin-hackers |
---|
From: | Erwin Brandstetter <brandstetter(at)falter(dot)at> |
---|---|
To: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Behavioral issues in data grid: unsaved data, sort/filter |
Date: | 2008-04-25 19:51:15 |
Message-ID: | 48123633.6010206@falter.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgadmin-hackers |
Hi developers! Hi Dave!
Testing pgAdmin v.1.8.2 (Feb 5 2008), rev: 7050, on WinXP; host: pg
8.2.7 and 8.3.1 on Debian Etch
If I change data in the data grid and try to close the window or refresh
before saving, I get a warning:
There is unsaved data in a row.
Do you want to store to the database?
Which is a very welcome feature. However, this behaviour is unreliable
for various reasons.
I compile this report after I have lost data in a complex operation
handling multiple tables when I did not pay close attention. The
recovery is painful. It is probably save to assume, that if I was not
fully aware of the nuances in behavior, then hardly any user is.
I'll best demonstrate with a simple test-case:
CREATE TABLE test
( id integer primary key,
txt1 text,
txt2 text);
INSERT INTO test
VALUES(1,'foo', 'bar'), (2,'foo2', 'bar2'), (3,'foo3', 'bar3');
Actually, this is only included for completeness. You can use any table
with any data.
Now, open the data grid on this table and do stuff.
I added what happens at attempts to close/refresh as comment after each line
- click a field once, selected -- exit without warning, OK
- click it a 2nd time, enter edit mode with all data selected
-- exit leaves edit mode, issues a FALSE warning about unsaved data
(no data was changed)
or - press <F2>, enter edit mode with all data selected -- the same
- click a 3rd time, unselect data, position cursor -- the same
- change data -- exit leaves edit mode, issues warning, OK
- move on with <tab>, leave edit mode, next field selected
-- exit without warning, DATA LOST
or - move on with <shift><tab>, leave edit mode, prev. field selected
-- the same (probably due to a known issue we have been discussing
like a year ago.)
or - move on by clicking another field of the same row, leave edit mode,
new field selected -- exit with warning, OK
or - move on by clicking another field of of another row, leave edit
mode, auto-save row, new field selected -- exit without warning, OK
IF you change more fields, the warning will be given in any case.
Well, almost any case. There is still the sort/filter dialog. Try one of
the following with unsaved changes:
- add a new filter, press [OK] -- DATA LOST without warning,
regardless if the row is still displayed
- edit a present filter, press [OK] -- DATA LOST without
warning, regardless if the row is still displayed
- open a present filter, but do not change, press [OK] --
nothing happens, data are not refreshed, which is wrong for a different
reason: the underlying data may have changed. Pressing [OK] on a filter
means the user wants to apply it.
- open a present filter, add irrelevant whitespace somewhere in the
middle, press [OK] -- filter is reapplied, as it should be. But
DATA LOST without warning
Similar problems when changing sort order.
How it should be:
~~~~~~~~~~~~
- Do not warn, if data has not changed
- Do warn, if data has changed. Not only at attempts to close the
window, but also on any attempt to requery, including sort/filter.
While being at it, requery _every_ time [OK] is clicked - as opposed
to [Cancel] - in the sort/filter dialog.
It is futile to check for changes in filter/sort, as the underlying
data may have changed, and it is confusing if a meaningless whitespace
makes all the difference.
The user can always click [Cancel] if he does not want to requery.
Regards
Erwin
From: | "Dave Page" <dpage(at)pgadmin(dot)org> |
---|---|
To: | "Erwin Brandstetter" <brandstetter(at)falter(dot)at> |
Cc: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: Behavioral issues in data grid: unsaved data, sort/filter |
Date: | 2008-05-02 11:03:09 |
Message-ID: | 937d27e10805020403s26340a4eva705ea53253cd22a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgadmin-hackers |
Hi Erwin,
On Fri, Apr 25, 2008 at 8:51 PM, Erwin Brandstetter
<brandstetter(at)falter(dot)at> wrote:
> - Do not warn, if data has not changed
OK, that's the hard one. I don't know how we can do that without some
fairly extensive work. I'll add it to the todo list. On the plus side,
that's an annoyance, not a data loss bug.
> - Do warn, if data has changed. Not only at attempts to close the window,
> but also on any attempt to requery, including sort/filter.
I've committed a patch that should fix this.
> While being at it, requery _every_ time [OK] is clicked - as opposed to
> [Cancel] - in the sort/filter dialog.
> It is futile to check for changes in filter/sort, as the underlying data
> may have changed, and it is confusing if a meaningless whitespace makes all
> the difference.
> The user can always click [Cancel] if he does not want to requery.
That's more of a debatable change but I think you're correct and have
committed the change.
Thanks, Dave.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
From: | Erwin Brandstetter <brandstetter(at)falter(dot)at> |
---|---|
To: | dpage(at)pgadmin(dot)org |
Cc: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: Behavioral issues in data grid: unsaved data, sort/filter |
Date: | 2008-05-02 15:33:50 |
Message-ID: | 481B345E.50601@falter.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgadmin-hackers |
Hi Dave!
Great! I am looking forward to the new point release. :)
dpage(at)pgadmin(dot)org wrote:
> Hi Erwin,
>
> On Fri, Apr 25, 2008 at 8:51 PM, Erwin Brandstetter
> <brandstetter(at)falter(dot)at> wrote:
>
(...)
>> - Do warn, if data has changed. Not only at attempts to close the window,
>> but also on any attempt to requery, including sort/filter.
>>
>
> I've committed a patch that should fix this.
>
Does that include the peculiar case, where the <tab> key makes the data
grid forget about changes? (When pressed after the first edit and as
opposed to moving on by mouse.)
Regards
Erwin
From: | "Dave Page" <dpage(at)pgadmin(dot)org> |
---|---|
To: | "Erwin Brandstetter" <brandstetter(at)falter(dot)at> |
Cc: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: Behavioral issues in data grid: unsaved data, sort/filter |
Date: | 2008-05-02 16:03:20 |
Message-ID: | 937d27e10805020903g6918025ewdb90df7dad69730a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgadmin-hackers |
On Fri, May 2, 2008 at 4:33 PM, Erwin Brandstetter
<brandstetter(at)falter(dot)at> wrote:
> Does that include the peculiar case, where the <tab> key makes the data grid
> forget about changes? (When pressed after the first edit and as opposed to
> moving on by mouse.)
I need to play with that some more.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
From: | "Dave Page" <dpage(at)pgadmin(dot)org> |
---|---|
To: | "Erwin Brandstetter" <brandstetter(at)falter(dot)at> |
Cc: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: Behavioral issues in data grid: unsaved data, sort/filter |
Date: | 2008-05-02 21:48:42 |
Message-ID: | 937d27e10805021448o2bff4f32r7356fc6eb8c6c826@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgadmin-hackers |
On Fri, May 2, 2008 at 5:03 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Fri, May 2, 2008 at 4:33 PM, Erwin Brandstetter
> <brandstetter(at)falter(dot)at> wrote:
>
> > Does that include the peculiar case, where the <tab> key makes the data grid
> > forget about changes? (When pressed after the first edit and as opposed to
> > moving on by mouse.)
>
> I need to play with that some more.
OK, I've done some playing and uploaded a windows build to
http://developer.pgadmin.org/~dpage/pgAdmin3.zip (iirc, you usually
test on Windows). Please give it a whirl - I believe I've fixed the
<tab> case, but I want to be sure there are no regressions I've missed
as this seems reasonable to include in 1.8.3.
Thanks, Dave
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
From: | Erwin Brandstetter <brandstetter(at)falter(dot)at> |
---|---|
To: | dpage(at)pgadmin(dot)org |
Cc: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: Behavioral issues in data grid: unsaved data, sort/filter |
Date: | 2008-05-02 23:57:50 |
Message-ID: | 481BAA7E.7080607@falter.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgadmin-hackers |
Hi Dave!
dpage(at)pgadmin(dot)org wrote:
> OK, I've done some playing and uploaded a windows build to
> http://developer.pgadmin.org/~dpage/pgAdmin3.zip (iirc, you usually
> test on Windows). Please give it a whirl - I believe I've fixed the
> <tab> case, but I want to be sure there are no regressions I've missed
> as this seems reasonable to include in 1.8.3.
Right, thanks, I mainly use WinXP as desktop, the transition to Ubuntu
8.04/ Debian Lenny is imminent, though.
Testing pgAdmin v.1.9.0-Dev (May 2 2008), rev: 7245:7266M, on WinXP;
host: pg 8.2.7 and 8.3.1 on Debian Etch.
I have played around a bit and run the same tests as before. AFAICS,
you've nailed all mentioned cases of potential data loss, which is the
most important part.
- <tab> key now seems to have the same effect as moving to the next
field with the mouse pointer. This is a twofold improvement: no data
loss, behavior unified.
The false warnings have consequently become more frequent. It is the
lesser evil, if we have to chose.
- Save warning now fires, if I engage sort/filter, which prevents data loss.
It might be even smarter to wait until sort/filter is actually
applied. If one just wants to look up the filter or decides to [CANCEL]
for any other reason, then we may not need the warning. But that's a
minor point.
- [Cancel] or [OK] now abort or apply sort/filter just the way it should
be IMO.
I've also checked for the other stuff I have reported recently and
replied on the thread where I've come up with something.
The rest seems to work like a charm now. Also no crashes or anything bad
and new.
- Rule privilege for VIEWs: partly fixed, see reply on thread.
- Refresh object name: seems FIXED.
- "FORCE" option for REINDEX: seems Robins FIXED it.
- Redundant double-quotes in types: seems FIXED.
- Errors & notices in pgAdmin log-files: seems FIXED.
Regards
Erwin
From: | "Dave Page" <dpage(at)pgadmin(dot)org> |
---|---|
To: | "Erwin Brandstetter" <brandstetter(at)falter(dot)at> |
Cc: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: Behavioral issues in data grid: unsaved data, sort/filter |
Date: | 2008-05-03 07:18:58 |
Message-ID: | 937d27e10805030018y509b2a3at2aa6c9544dd39bae@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgadmin-hackers |
Hi Erwin,
On Sat, May 3, 2008 at 12:57 AM, Erwin Brandstetter
<brandstetter(at)falter(dot)at> wrote:
> - <tab> key now seems to have the same effect as moving to the next field
> with the mouse pointer. This is a twofold improvement: no data loss,
> behavior unified.
> The false warnings have consequently become more frequent. It is the lesser
> evil, if we have to chose.
>
> - Save warning now fires, if I engage sort/filter, which prevents data loss.
> It might be even smarter to wait until sort/filter is actually applied. If
> one just wants to look up the filter or decides to [CANCEL] for any other
> reason, then we may not need the warning. But that's a minor point.
>
> - [Cancel] or [OK] now abort or apply sort/filter just the way it should be
> IMO.
>
>
> I've also checked for the other stuff I have reported recently and replied
> on the thread where I've come up with something.
> The rest seems to work like a charm now. Also no crashes or anything bad and
> new.
>
> - Rule privilege for VIEWs: partly fixed, see reply on thread.
> - Refresh object name: seems FIXED.
> - "FORCE" option for REINDEX: seems Robins FIXED it.
> - Redundant double-quotes in types: seems FIXED.
> - Errors & notices in pgAdmin log-files: seems FIXED.
Wow, that's quick work. Thanks for the usual high standard of testing
- I'll check the rule priv thing in a couple of days. guess I just
overlooked a spot - patience never was my strong point.
Cheers, Dave
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com