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

Behavioral issues in data grid: unsaved data, sort/filter

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 (view raw or flat)
Thread:
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

Responses

pgadmin-hackers by date

Next:From: Robins TharakanDate: 2008-04-27 23:43:22
Subject: frmEditGrid Crash testcase
Previous:From: Dave PageDate: 2008-04-25 10:29:21
Subject: Re: Broken 1.8.2 source tar ball?

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