Bug 1436 - save changes: save only valid features, while ignoring invalid ones
James Nordgaard
A user presses Save and gets an error message. Added to this message is something like, "If you are trying to save, press Save again to get more options."
If the user presses Save a second time (without changing the edits) s/he gets the following popup:
An error occurred during the previous attempt to save your changes. You have the following options:
-Try to save again (save all changes as a whole).
-Cancel here, then edit your work to try to eliminate the source of the problem. Usually this involves pressing 'Undo' several times then trying to save again, until you can save successfully. The undone edits will be lost after a successful save.
-Try a partial save. Any individual edits that can't be integrated into the map database will be lost, All other edits will be saved. It is important to review all your changes after doing a partial save (the changes will be outlined), because it may generate errors on the map do to the edits that weren't saved.
-Cancel here and press Discard to permanently discard all changes, and start over.
The popup will have buttons for Save, Partial Save, and Cancel.
Note: If a partial save fails to save anything (like with a communications problem), the edits remain unsaved for the user to decide what to do next.
After a successful partial save, that revision gets automatically selected, so the user's successful changes will be outlined for the user to review.
Landon Bouma
Is this easily reproducible?
Are there certain steps we can perform to recreate this problem?
To be honest, I've seen the code for these dialogs, but I've never seen the problem myself. That said, I'm almost always testing against my own box and not the production server (i.e., against http://magic.cyclopath.org).
I guess I'm asking two things, really -- (1) is this easily reproducible, and (2) does this happen a lot?
Thanks again for all your help, Jim.
Sincerely,
Landon
--
You received this message because you are subscribed Cyclopath Development.
To post to this group: send email to cyclop...@googlegroups.com
To read this group on the Web: http://groups.google.com/group/cyclopath-dev
To unsubscribe from this group: send email to
cyclopath-de...@googlegroups.com
To unsubscribe from this group, send email to cyclopath-dev+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
James Nordgaard
I would love to solve this problem!
Is this easily reproducible?
Are there certain steps we can perform to recreate this problem?
To be honest, I've seen the code for these dialogs, but I've never seen the problem myself. That said, I'm almost always testing against my own box and not the production server (i.e., against http://magic.cyclopath.org).
I guess I'm asking two things, really -- (1) is this easily reproducible,
The answer is yes.
There are two general circumstances where this crops up:
First, unknown bugs that a user accidentally stumbles upon editing. This has happened to me (see below).
The second has been documented; see http://bugs.grouplens.org/show_bug.cgi?id=1337 The error you get has since changed; you get a vague, actually misleading message (see http://bugs.grouplens.org/show_bug.cgi?id=1437 ).
To reproduce simply open two sessions, edit the same feature in each, and save in each.
and (2) does this happen a lot?
No. I have done a *lot* of editing, and it's happened maybe three or four times. But I still think it important to do something about this. It's not good form to allow a user to lose all their work just because a single edit triggered some obscure bug, or got changed by another user.
Reid Priedhorsky
> On Tue, Mar 23, 2010 at 12:38 AM, Landon Bouma <lan...@cs.umn.edu> wrote:
>
>> I would love to solve this problem!
>>> -Try a partial save. Any individual edits that can't be integrated into
>>> the map database will be lost, All other edits will be saved. It is
>>> important to review all your changes after doing a partial save (the changes
>>> will be outlined), because it may generate errors on the map do to the edits
>>> that weren't saved.
I agree, and I'd like a way to protect users from unexpected problems.
I don't see exactly how to determine what the appropriate partial save
is. When there's a failure, the server doesn't know which feature in the
save was the culprit and it's not possible to make this identification
robustly. So figuring out what the right partial save is has be
iterative somehow - and spraying data at the server until something
sticks sounds risky to me.
In the specific case of simultaneous edits to the same feature, for some
time we've wanted a way to untangle these conflicts (e.g.,
http://bugs.grouplens.org/show_bug.cgi?id=1337), and it's
straightforward to identify this case (it will be a primary key error).
In this case what I think we want is conflict-resolution code, not
partial saves.
Reid
James Nordgaard
As for simultaneous edits, I agree we should deal with it better than a partial save; it was a case of 'until then..'
Yes iterative is kind of ugly. But if we had no way to handle unforeseen errors; what about two phase commits? Admittedly, my knowledge of databases is dismal. But a post I found said "If the precommit succeeds, then the database is telling you that it guarantees that the commit will succeed " So in principle you could prepare/rollback each edit to find which to throw out before committing the partial save.
It just occurred to me that it's possible for an error to occur only with a combination of the edits. Ugg. I don't know how common this is.
Anyway, I'll abandon the effort for now.
Thanks,
Jim
Reid Priedhorsky
something more optimistic and failed.
> Yes iterative is kind of ugly. But if we had no way to handle unforeseen
> errors; what about two phase commits? Admittedly, my knowledge of databases
> is dismal. But a post I found said "If the precommit succeeds, then the
> database is telling you that it guarantees that the commit will succeed " So
> in principle you could prepare/rollback each edit to find which to throw out
> before committing the partial save.
Two-phase commit doesn't apply in this case (it's at a lower level), but
I can see where you're coming from: we could iteratively save rows and
if one row failed, remove it, back up, and proceed.
The drawback of this approach is that it's very handy to let a partial
transaction be internally inconsistent: for example, ratings have to
refer to blocks that exist, but it's nice to be able to save all ratings
before any blocks. If we delay the consistency check until we commit, we
don't have to worry about these temporary inconsistencies. (This is why
all the foreign keys are declared DEFERRABLE and transactions begin with
SET CONSTRAINTS ALL DEFERRED.)
So, we can't currently guarantee that a row is valid until we try to
commit the whole transaction.
> It just occurred to me that it's possible for an error to occur only with a
> combination of the edits. Ugg. I don't know how common this is.
It happens sometimes, though I also don't know how common it is.
Reid
James Nordgaard
We'd have to give some thought about what to tell the user. Do we ask the user whether or not they want to 'submit' the failed revision to the team, or just inform them that the revision has been recorded, and someone will be looking into the matter? Either way, we'd inform the user that there is no guarantee that the revision will eventually get implemented, and that the user can make further edits immediately, including redoing the edits from the failed revision.
The developer will of course have to allow for intermediate changes to the map, when committing the revision.
Is this feasible?
Jim
Michael Ludwig
the server, we save both the error and the request which generated the
error. It has often been the case that we can identify the problems
within the save by looking at the request. Unfortunately, I'm not
sure if it's the developer's place to try to guess what the user
intended to save.
-Michael