Opened 14 years ago

Closed 14 years ago

#379 closed defect (fixed)

Deleting an element can remove the following element.

Reported by: justinrowles Owned by: mcoudert
Priority: critical Milestone: v2.6.3
Component: General Version: v2.6.1
Keywords: Cc:

Description

If an element is removed which is the last of its kind, but not the last in its parent, the geonet:child element created overwrites the following element.

Attachments (2)

deleteElementOverwritesElement.diff (1.5 KB ) - added by justinrowles 14 years ago.
deleteElementOverwritesElement.patch (1.5 KB ) - added by mcoudert 14 years ago.

Download all attachments as: .zip

Change History (8)

by justinrowles, 14 years ago

comment:1 by justinrowles, 14 years ago

Priority: majorcritical

The attached diff makes two changes.

(1) The new geonet:child element in INSERTED at the index from which the old element was deleted. Previously it was SET, which overwrote anything following the element to be deleted.

(2) There was a null pointer exception caused by a log instead of a throw IllegalStateException (which is what is done at similar points), where the code went on to dereference the null element anyway.

comment:2 by mcoudert, 14 years ago

Owner: changed from geonetwork-devel@… to mcoudert
Status: newassigned

(1) sounds good to François and me after a quick talk.

(2) I would suggest to skip this element and to log the error. This case should never happens. Throwing an exception here will lead to loose all changes posted in the editor and to get an error pop up not very explicit.

Please find my new patch attached.

by mcoudert, 14 years ago

comment:3 by justinrowles, 14 years ago

I think the exception throw version is better.

If you use this new patch, then the "el" variable is dereferenced anyway, so you get a NullPointerException at one of lines 1533, 1545 or 1549. This loses all your changes anyway, and gives you no context for the error.

Whether it *should* happen or not is immaterial! ;) I only changed it because it *did* happen (because of the other bug) and I had to debug from the NPE.

comment:4 by mcoudert, 14 years ago

The "continue" statement avoid to get a NPE, which is in my opinion the main issue. Concerning the fact to log an error or to throw an exception I would say let's discuss it at the next IRC meeting.

(2) This fix should probably be applied at other places in GeoNetwork, where the "Element not found at ref..." is returned. To be checked.

comment:5 by justinrowles, 14 years ago

Apologies, I didn't see the 'continue'. You're right, there won't be an NPE.

Personally I'd rather not silently ignore evidence of a mismatch between the front and back ends, as then the user will believe changes have been saved that have in fact been ignored. If it should never happen then there's no reason not to throw an exception. YMMV.

I can't make IRC I'm afraid. No IRC access here. Let's stand on opposite sides of the Channel / La Manche and throw rocks at each other to decide :)

comment:6 by mcoudert, 14 years ago

Resolution: fixed
Status: assignedclosed

Committed revision 6889.

Note: See TracTickets for help on using tickets.