Обсуждение: Results from testing RC2, rev: 5607:5627M
Hi developers! Hi Dave!
Dave, I have tested the new version you sent me. RC2, rev: 5607:5627M.
(5627M?)
- No crashes or anything major sighted in two hours of testing (mainly
edit grid).
- You have definitely improved the handling of timestamps, dates and
intervals. Copy & paste is much more convenient now, as you don't have
to worry about linebreak proliferation.
If this blessing could be extended to text types one day, then halleluja. :)
- Starting new lines by inserting data is now less confusing, the new
dialogue prevents data loss. And the option to cancel the operation is a
major improvement. That's the one I will be using 99% of the time.
The current way of handling cursor and selection will remain prone to
errors and cornercases, though.
- The undead "undo" issue:
The save dialogue pops up, even if there is no data to save, even if I
did not enter edit mode in the row of the cursor at all, or if I set the
cursor on the "new" row. This isn't dangerous, but confusing.
If I answer yes to the uncalled-for save dialogue, then the rest of the
operation seems to be aborted (nothing happens).
When I tried all of this with another table, the phenomenon was gone. I
think I found the reason, finally:
The undo button gets activated as soon as I enter edit mode. (We have
been discussing this before.) If I do not change anything and leave the
field, undo button stays activated. Even if I set the cursor on another
row (no unsaved changes could be pending still). This will provoke the
above problems. Pressing the undo buton or <ctrl><z>, achieves nothing
but the reset of the undo button. After that, the above mentioned
problems are gone, until undo gets activated once more.
Interestingly, if I actually change data, then the changes are saved, as
soon as I set the cursor on another row, and the undo button is
deactivated. Obviously the undo button waits for a save to occur or the
changes to be undone, but if it has been activated without any changes
having been made, it will wait forever.
- While experimenting with pasting, I pasted the dummy text 'asdfg' to
an integer column and saved - which produced an error as expected. The
nature of the error was a bit of a surprise though:
An error has occurred: FEHLER: Spalte >>asdfg<< existiert nicht.
Meaning: "Error: Column >>asdfg<< does not exist."
Somehow data is being mistaken for a column name. This could possibly
lead to grave errors. (Or is it the German translation wrong?)
In my test-case it was the primary key and first column. See appended
definition, if you need.
Regards
Erwin
P.S.: For reference (in case you need it, maybe you don't), the
definition of the table I utilized for testing. Quickly derived &
simplified from a real table I use.
Table dumped with this command line (I have a "test" db-cluster on port
5433): pg_dump -p 5433 -f /var/lib/postgres/dev/test.sql -n cp -t test event
--
-- PostgreSQL database dump
--
SET client_encoding = 'UTF8';
SET check_function_bodies = false;
SET client_min_messages = warning;
SET search_path = cp, pg_catalog;
SET default_tablespace = '';
SET default_with_oids = false;
--
-- Name: test; Type: TABLE; Schema: cp; Owner: postgres; Tablespace:
--
CREATE TABLE test ( feld_id serial NOT NULL, tabelle text DEFAULT '?'::text NOT NULL, feld text DEFAULT '?'::text
NOTNULL, flabel text, sprechend boolean DEFAULT true NOT NULL, note text, log_up timestamp without time zone
NOTNULL, log_upby integer NOT NULL, ex boolean DEFAULT false NOT NULL, extime timestamp without time zone,
tlabeltext DEFAULT '?'::text NOT NULL, frang integer DEFAULT 10 NOT NULL, trang integer DEFAULT 10 NOT NULL
);
ALTER TABLE cp.test OWNER TO postgres;
--
-- Name: test_feld_id_seq; Type: SEQUENCE SET; Schema: cp; Owner: postgres
--
SELECT pg_catalog.setval(pg_catalog.pg_get_serial_sequence('test',
'feld_id'), 1, false);
--
-- Data for Name: test; Type: TABLE DATA; Schema: cp; Owner: postgres
--
COPY test (feld_id, tabelle, feld, flabel, sprechend, note, log_up,
log_upby, ex, extime, tlabel, frang, trang) FROM stdin;
502 adrkey keytyp_id Typ f Nummern-Typ 2006-07-06 18:14:02 1
f \N Zusatznummer 50 50
111 firma uid UID t \N 2006-07-06 18:14:02 1 f \N Firma 10 10
206 adr adrform_id Adressformat f \N 2006-07-06 18:14:02 1 f
\N Adresse 20 20
405 adrkat fixbearb_id id der Transaktion t \N 2006-08-08
20:39:59 1 f \N Zusatzbranche 40 40
704 firmaintern inseratvor07 Anzeigenkunde vor 07 t \N 2006-07-06
18:14:02 1 f \N Interne Daten 70 70
702 firmaintern dotcopy .copy t \N 2006-07-06 18:14:02 1 f \N
Interne Daten 70 70
701 firmaintern note Notiz t \N 2006-07-06 18:14:02 1 f \N
Interne Daten 70 70
103 firma vorbis Vorreihung t Firma wird bei Suchergebnissen im
Web bis zu diesem Datum vorgereiht. 2006-07-06 18:14:02 1 f \N
Firma 10 10
404 adrkat fixbis Fix bis t Erscheinen fixiert bis zu dieser
Ausgabe 2006-07-06 18:14:02 1 f \N Zusatzbranche 40 40
403 adrkat kattxt Branchen-Text t \N 2006-07-06 18:14:02 1 f
\N Zusatzbranche 40 40
406 adrkat hervorbis Hervorhebung bis t Hervorhebung der Branche
im Buch bis zu dieser Ausgabe. 2006-07-06 18:14:02 1 f \N
Zusatzbranche 40 40
504 adrkey hinweis Hinweis t \N 2006-07-06 18:14:02 1 f \N
Zusatznummer 50 50
503 adrkey wert Nummer t \N 2006-07-06 18:14:02 1 f \N
Zusatznummer 50 50
608 kontakt haupt Hauptkontakt t Es kann nur einen geben!
2006-07-06 18:14:02 1 f \N Kontakt 60 60
607 kontakt email E-Mail t \N 2006-07-06 18:14:02 1 f \N
Kontakt 60 60
606 kontakt tel Telefon t \N 2006-07-06 18:14:02 1 f \N
Kontakt 60 60
604 kontakt vorname Vorname t \N 2006-07-06 18:14:02 1 f \N
Kontakt 60 60
602 kontakt anrede Anrede t \N 2006-07-06 18:14:02 1 f \N
Kontakt 60 60
110 firma exby Ausgeschieden durch f \N 2006-07-06 18:14:02 1 f
\N Firma 10 10
109 firma extime Zeitpunkt des Ausscheidens t \N 2006-07-06
18:14:02 1 f \N Firma 10 10
108 firma ex Karteileiche t Angehakt für Karteileichen 2006-07-06
18:14:02 1 f \N Firma 10 10
107 firma valtime Freigabezeitpunkt t \N 2006-07-06 18:14:02 1 f
\N Firma 10 10
106 firma valby Freigabe durch f \N 2006-07-06 18:14:02 1 f \N
Firma 10 10
105 firma val Freigabe t Firma ist für Verwendung in Web & Buch
frei gegeben. 2006-07-06 18:14:02 1 f \N Firma 10 10
101 firma firma Name t Firmenbezeichnung 2006-07-06 18:14:02 1 f
\N Firma 10 10
204 adr hausnr Hausnummer t \N 2006-07-06 18:14:02 1 f \N
Adresse 20 20
203 adr str_id Straße/Adresse f Straße, PLZ, Ort, Land
2006-07-06 18:14:02 1 f \N Adresse 20 20
202 adr adr Bezeichnung t Bezeichnung der Niederlassung /
Zusatzadresse 2006-07-06 18:14:02 1 f \N Adresse 20 20
210 adr email Email t \N 2006-07-06 18:14:02 1 f \N Adresse 20 20
209 adr fax Fax t \N 2006-07-06 18:14:02 1 f \N Adresse 20 20
208 adr tel Telefon t \N 2006-07-06 18:14:02 1 f \N Adresse
20 20
205 adr adrzusatz Adresszusatz t \N 2006-07-06 18:14:02 1 f
\N Adresse 20 20
207 adr str_unclear Str.-Schreibweise unklar t Schreibweise der
Straße unklar. 2006-07-06 18:14:02 1 f \N Adresse 20 20
100 firma firma_id \N t Alle prim. keys sollen eigentlich nicht in
der Maske dargestellt werden, "id" sollte nirgendwo sichtbar
aufscheinen. 2006-07-06 18
200 adr adr_id \N t \N 2006-07-06 18:14:31 1 f \N Adresse 18 20
201 adr firma_id \N t \N 2006-07-06 18:14:35 1 f \N Adresse 19 20
400 adrkat adrkat_id \N t \N 2006-07-06 18:14:39 1 f \N
Zusatzbranche 38 40
401 adrkat adr_id \N t \N 2006-07-06 18:14:42 1 f \N
Zusatzbranche 39 40
500 adrkey adrkey_id !Sonderfall! Siehe cp.f_firma_wannachange!
f \N 2006-07-06 18:14:44 1 f \N Zusatznummer 48 50
501 adrkey adr_id !Sonderfall! Siehe cp.f_firma_wannachange! f
!ACHTUNG! Sonderfall Zusatznummer zu Zusatzadresse. 2006-07-06
18:14:49 1 f \N Z
700 firmaintern firma_id \N t \N 2006-07-06 18:14:55 1 f \N
Interne Daten 69 70
600 kontakt kontakt_id \N t \N 2006-07-06 18:14:58 1 f \N
Kontakt 58 60
703 firmaintern webinsert ?Webgrafik? t ?Feld löschen? 2006-07-14
18:03:21 1 f \N Interne Daten 70 70
705 firmaintern wiedervorlage Wiedervorlage t !ACHTUNG! feld_id =
705 hardcoded in Trigger cp.trg_c_insbef() 2006-07-11 18:37:56 1 f \N
Interne Daten
211 adr www Homepage t \N 2006-07-06 18:14:02 1 f \N Adresse
20 20
212 adr isdn ISDN t \N 2006-07-06 18:14:02 1 f \N Adresse 20 20
250 adr kat_id Branche f \N 2006-07-06 18:14:02 1 f \N
Hauptbranche 30 30
251 adr kattxt Branchen-Text t \N 2006-07-06 18:14:02 1 f \N
Hauptbranche 30 30
252 adr hervorbis Hervorhebung bis t Im Buch wird Branche
zuletzt in dieser Nummer hervorgehoben. 2006-07-06 18:14:02 1 f \N
Hauptbranche 30 3
402 adrkat kat_id Branche f \N 2006-07-06 18:14:02 1 f \N
Zusatzbranche 40 40
253 adr hervorbearb_id id der Transaktion t \N 2006-08-08
17:25:13 1 f \N Hauptbranche 30 30
407 adrkat hervorbearb_id id der Transaktion t \N 2006-08-08
17:25:19 1 f \N Zusatzbranche 40 40
102 firma fzusatz Zusatzname t Zusatz zum Firmennamen 2006-11-13
20:49:13 1 f 2006-11-06 18:14:02 Firma 10 10
104 firma vorbearb_id id der Transaktion t \N 2006-11-13 20:49:27
1 f 2006-11-06 18:14:02 Firma 10 10
\.
--
-- Name: test_pkey; Type: CONSTRAINT; Schema: cp; Owner: postgres;
Tablespace:
--
ALTER TABLE ONLY test ADD CONSTRAINT test_pkey PRIMARY KEY (feld_id);
--
-- Name: test_uni; Type: CONSTRAINT; Schema: cp; Owner: postgres;
Tablespace:
--
ALTER TABLE ONLY test ADD CONSTRAINT test_uni UNIQUE (tabelle, feld);
--
-- PostgreSQL database dump complete
--
brandstetter@falter.at wrote: > - The undead "undo" issue: > The save dialogue pops up, even if there is no data to save, even if I > did not enter edit mode in the row of the cursor at all, ... To clarify: the new save dialogue when pasting a new row by pressing <ctrl><v> while not in edit mode. /Erwin
Hi developers! Hi Dave! brandstetter@falter.at wrote: > - While experimenting with pasting, I pasted the dummy text 'asdfg' to > an integer column and saved - which produced an error as expected. The > nature of the error was a bit of a surprise though: > > An error has occurred: > FEHLER: Spalte >>asdfg<< existiert nicht. > > Meaning: "Error: Column >>asdfg<< does not exist." > Somehow data is being mistaken for a column name. This could possibly > lead to grave errors. (Or is it the German translation wrong?) > Checking the the log-file reveals the cause: 2006-11-13 21:49:22 CET postgres FEHLER: Spalte »asdfg« existiert nicht 2006-11-13 21:49:22 CET postgres ANWEISUNG: INSERT INTO cp.test(feld_id) VALUES (asdfg::integer) This should read 'asdfg'::integer (with single quotes), as long as you don't make sure the data is numeric in the first place. Could have nasty side-effects otherwise. Home-made 'SQL-injection'? Or is this by design, so you _can_ enter function calls? (But then again, that would not play well with the rest of the application.) Actually, I entered a function call and it was evaluated. Subsequent operations on the new row showed a variety of weird effects. Another sample from the log: Note how the value is being quoted in the WHERE-clause, when trying to change the newly inserted row. Note also, that the WHERE clause is quite nonsensical for a integer column. 2006-11-13 23:59:03 CET postgres ANWEISUNG: SELECT * FROM cp.feld WHERE feld_id = 'cp.f_ausgabe_id()'::integer 2006-11-13 23:59:11 CET postgres FEHLER: ungültige Eingabesyntax für ganze Zahl: »cp.f_ausgabe_id()« 2006-11-13 23:59:11 CET postgres ANWEISUNG: UPDATE cp.feld SET feld_id=NULL::integer WHERE feld_id = 'cp.f_ausgabe_id()'::integer 2006-11-13 23:59x:35 CET postgres FEHLER: duplizierter Schlüssel verletzt Unique-Constraint »feld_pkey« 2006-11-13 23:59:35 CET postgres ANWEISUNG: INSERT INTO cp.feld(feld_id) VALUES (cp.f_ausgabe_id()::integer) 2006-11-13 23:59:55 CET postgres FEHLER: ungültige Eingabesyntax für ganze Zahl: »cp.f_ausgabe_id()« 2006-11-13 23:59:55 CET postgres ANWEISUNG: SELECT * FROM cp.feld WHERE feld_id = 'cp.f_ausgabe_id()'::integer Regards Erwin
Erwin Brandstetter wrote: > - Starting new lines by inserting data is now less confusing, the new > dialogue prevents data loss. And the option to cancel the operation is a > major improvement. That's the one I will be using 99% of the time. > The current way of handling cursor and selection will remain prone to > errors and cornercases, though. Maybe - but I think they really are corner cases for the most part. You're pretty much the only complainant in 5 years or so! (not that I'm saying they shouldn't be fixed you understand). > > - The undead "undo" issue: > The save dialogue pops up, even if there is no data to save, even if I > did not enter edit mode in the row of the cursor at all, or if I set the > cursor on the "new" row. This isn't dangerous, but confusing. > If I answer yes to the uncalled-for save dialogue, then the rest of the > operation seems to be aborted (nothing happens). Yeah, think I've got this case nailed. Will send you an exe for testing. > > - While experimenting with pasting, I pasted the dummy text 'asdfg' to > an integer column and saved - which produced an error as expected. The > nature of the error was a bit of a surprise though: > > An error has occurred: > FEHLER: Spalte >>asdfg<< existiert nicht. > > Meaning: "Error: Column >>asdfg<< does not exist." > Somehow data is being mistaken for a column name. This could possibly > lead to grave errors. (Or is it the German translation wrong?) Hmm. This only happens because the underlying text control handles it's own paste operations - when you type into a numeric field, we filter out invalid characters (ie. alpha), but when pasting that doesn't happen. That will take some real effort to resolve properly. For now, I've just made sure that numeric data gets quoted to remove the column/funtion ambiguity with unquoted text. That will at least ensure that the user gets a sensible error message from the server. Regards, Dave.
Hi Dave! Testing 1.6 RC2 rev: 5634:5635 on Win XP- the one you've sent me. You've got both issues fixed. The application keeps getting better. :) I found remaining corners in both cases, but of very limited impact. So if you are tired of this, you might as well skip the rest of the mail. dpage@postgresql.org wrote: > Erwin Brandstetter wrote: > >> - Starting new lines by inserting data is now less confusing, the new >> dialogue prevents data loss. And the option to cancel the operation >> is a major improvement. That's the one I will be using 99% of the time. >> The current way of handling cursor and selection will remain prone to >> errors and cornercases, though. > > Maybe - but I think they really are corner cases for the most part. > You're pretty much the only complainant in 5 years or so! (not that > I'm saying they shouldn't be fixed you understand). Sure, I understand. Still, some features (like pasting rows) are new in v1.6. And beta-testers like me are "early complainers" by nature. ;) >> >> - The undead "undo" issue: >> The save dialogue pops up, even if there is no data to save, even if >> I did not enter edit mode in the row of the cursor at all, or if I >> set the cursor on the "new" row. This isn't dangerous, but confusing. >> If I answer yes to the uncalled-for save dialogue, then the rest of >> the operation seems to be aborted (nothing happens). > > Yeah, think I've got this case nailed. Will send you an exe for testing. So you didn't skip? Curiosity killed the cat! ;) The remaining cornercase here: As long as I stay within the edited row, the previously described issue will kick in. When undo is active while nothing has been changed, the save dialogue will pop up, and if I say yes, then rest of the operation will be cancelled silently. No saving (of course - nothing changed), but no pasting either. But now I can get rid of this by clicking outside the row, so the scale of the issue has been diminished. >> - While experimenting with pasting, I pasted the dummy text 'asdfg' >> to an integer column and saved - which produced an error as expected. >> The nature of the error was a bit of a surprise though: >> >> An error has occurred: >> FEHLER: Spalte >>asdfg<< existiert nicht. >> >> Meaning: "Error: Column >>asdfg<< does not exist." >> Somehow data is being mistaken for a column name. This could possibly >> lead to grave errors. (Or is it the German translation wrong?) > > Hmm. This only happens because the underlying text control handles > it's own paste operations - when you type into a numeric field, we > filter out invalid characters (ie. alpha), but when pasting that > doesn't happen. That will take some real effort to resolve properly. > > For now, I've just made sure that numeric data gets quoted to remove > the column/funtion ambiguity with unquoted text. That will at least > ensure that the user gets a sensible error message from the server. That takes care of it, mostly. Unlike with text fields the new quoting in numeric fields does not escape quotes in the pasted data. If there is no specific reason for the deviation, you might consider adapting the behaviour for text fields to prevent weird effects. Told ya to skip the rest. :p Regards Erwin
Bah, clearly I'm a sucker for punishment... Erwin Brandstetter wrote: > So you didn't skip? Curiosity killed the cat! ;) > The remaining cornercase here: > As long as I stay within the edited row, the previously described issue > will kick in. > When undo is active while nothing has been changed, the save dialogue > will pop up, and if I say yes, then rest of the operation will be > cancelled silently. No saving (of course - nothing changed), but no > pasting either. > > But now I can get rid of this by clicking outside the row, so the scale > of the issue has been diminished. Figured out a way to check for modification more sensibly, so we can now disable the buttons on column change. > That takes care of it, mostly. > Unlike with text fields the new quoting in numeric fields does not > escape quotes in the pasted data. > If there is no specific reason for the deviation, you might consider > adapting the behaviour for text fields to prevent weird effects. Will be escaped properly now. > Told ya to skip the rest. :p Yeah, well. .exe en-route. If you can confirm things look good before tomorrow early-AM-GMT that would be very helpful :-) Cheers, Dave.