Opened 17 years ago

Closed 15 years ago

Last modified 14 years ago

#131 closed defect (fixed)

PostGIS digitizing

Reported by: cavallini@… Owned by: gsherman
Priority: minor: annoyance Milestone:
Component: Vectors Version: Trunk
Keywords: PostGIS database digitizing Cc:
Must Fix for Release: No Platform: All
Platform Version: etch Awaiting user input: no


When committing PostGIS digitizing changes to database, in case of even a single error in input (value not allowed) all the editing is lost. Too bad for serious work.

Change History (13)

comment:1 by mhugent, 17 years ago

Milestone: Version 0.8 ReleaseVersion 0.9 Release

comment:2 by morb_au, 17 years ago

Can you provide an example where "value not allowed" occurs?

There are always going to be cases where there may be an error when committing (e.g. disk full, server fallen off network) - perhaps we could do a "save changes but keep editing" feature?

comment:3 by venturato@…, 17 years ago

1 example: ERROR: insert or update on table "fix_2006" violates foreign key constraint "verifica_id_radio" DETAIL: Key (id_radio,anno)=(1000,2006) is not present in table "radio_usate".

2 example: ERROR: date/time field value out of range:"31/2/2006".

"save changes but keep editing" might be good, but I think it is better if qgis could keep it im memory, asking the user to edit the wrong value.

comment:4 by morb_au, 17 years ago

Owner: changed from gsherman to morb_au
Platform: DebianAll
Status: newassigned

I see where the problem is and have devised a potential fix on my machine. I'll commit it to subversion in the next few days and let you see if it works for you.

comment:5 by morb_au, 17 years ago

Component: DigitisingVectors
Milestone: Version 0.9 ReleaseVersion 0.8 Release

Should be fixed in r5591 for both changed attribute values and changed geometries. Can this be tested and the bug closed if appropriate?

comment:6 by cavallini@…, 17 years ago

The following error now appears (twice) when committing: ERROR: syntax error at or near "," at character 318 From the database side, we get: WARNING: non c'è nessuna transazione in corso and then: ERROR: current transaction is aborted, commands ignored until end of transaction block As a result, no data can be input.

comment:7 by g_j_m, 17 years ago

Resolution: fixed
Status: assignedclosed

The syntax error problem has been fixed in SVN r5637. Was a problem with blank data fields.

comment:8 by morb_au, 17 years ago

Further to my commentary on 07/14/06, I got to test it out and it was found wanting. r5694 should really fix it, I have put a full writeup on the commit message to r5694.

comment:9 by venturato@…, 17 years ago

Resolution: fixed
Status: closedreopened

Further testing: the situation is already much better than before, but in my view the correct behaviour would be for the program to stop and display the alphanumumeric digitizing window of the wrong record, so that the user could put the correct values. Admittedly, in case of errors in multiple records this would be difficult to implement. Perhaps better to automatically commit every record just after insertion?

Additionally, we get frequent crashes while digitizing.

comment:10 by g_j_m, 17 years ago

Can you provide a gdb backtrace for when it crashes please. Perhaps it is related to ticket #155?

comment:11 by morb_au, 17 years ago

Milestone: Version 0.8 ReleaseVersion 0.9 Release
Owner: changed from morb_au to gsherman
Status: reopenednew

The kind of refinement described in 08/29/06 15:53:14 is no longer a trivial change, and so I will push back that aspect of it to a post-0.8 timeframe.

Even then it would be fairly difficult to address any more than the first error in a commit. Maybe for each change, the postgres provider could do a BEGIN / UPDATE x where y / ROLLBACK sequence (testing to see if the UPDATE worked but without committing the change), but this would be unique to the postgres provider.

Therefore an architectural approach should be made to this instead of a quick fix.

comment:12 by jef, 15 years ago

Awaiting user input: unset
Must Fix for Release: No
Resolution: fixed
Status: newclosed

seems this was reintroduced at some point, but:

Editing is not stopped when a commit failure happens and the data is therefore not lost (fixed in r8210).

If the commit failure is caused by invalid values (e.g. strings in a numeric column) you can correct them in the attribute table and retry the commit afterwards (fixed in r8211).

comment:13 by (none), 14 years ago

Milestone: Version 0.9.2

Milestone Version 0.9.2 deleted

Note: See TracTickets for help on using tickets.