Modify

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#16515 closed enhancement (wontfix)

CommandStack is getting cleaned when uploading

Reported by: farin2 Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: upload undo redo command stack Cc:

Description

I've just mapped for 2 hours, then deleted most of my mappings (because they shouldn't get uploaded) and uploaded the rest to OSM.

After this the command history with all my mappings was gone. Which source code is exactly responsible for that?

Thanks for your help.

Attachments (0)

Change History (10)

comment:1 by Don-vip, 6 years ago

In OsmDataLayer:

    /**
     * Clean out the data behind the layer. This means clearing the redo/undo lists,
     * really deleting all deleted objects and reset the modified flags. This should
     * be done after an upload, even after a partial upload.
     *
     * @param processed A list of all objects that were actually uploaded.
     *         May be <code>null</code>, which means nothing has been uploaded
     */
    public void cleanupAfterUpload(final Collection<? extends IPrimitive> processed) {
        // return immediately if an upload attempt failed
        if (processed == null || processed.isEmpty())
            return;

        MainApplication.undoRedo.clean(data); // << here

        // if uploaded, clean the modified flags as well
        data.cleanupDeletedPrimitives();
        data.beginUpdate();
        try {
            for (OsmPrimitive p: data.allPrimitives()) {
                if (processed.contains(p)) {
                    p.setModified(false);
                }
            }
        } finally {
            data.endUpdate();
        }
    }

The use case where some actions are rolled back before uploaded has never been taken into account.

If you ask about code location, are you considering providing a patch?

comment:2 by Don-vip, 6 years ago

Keywords: upload undo redo command stack added

comment:3 by stoecker, 6 years ago

I doubt getting command stack and after-upload state in sync is worth the effort.

comment:4 by farin2, 6 years ago

I've recompiled without the specific line, even replaced the whole block with return; – but this didn't have the desired effect.

comment:5 by Don-vip, 6 years ago

Resolution: wontfix
Status: newclosed
Type: defectenhancement

This is a lot more complex than that. Also it would cause a serious performance penalty to keep modifications in memory after upload for long mapping sessions.

comment:6 by farin2, 6 years ago

@Don-vip wontfix is OK for me, but please give a little bit information that I can create my own patch.

comment:7 by Don-vip, 6 years ago

The patch would not be accepted. Don't waste your time on this.

comment:8 by farin2, 6 years ago

The patch would not be accepted.

I know, I knew for all the time. I would like to create a patch for no other user than myself. I will publish it, but just on private homepage to follow copyleft.

comment:9 by Don-vip, 6 years ago

If you really want to go this way to have to get familiar with everything that happens when a primitive is uploaded, and details about every type of commands to see what is needed to change to be able to undo them on a primitive that has been uploaded. This is huge work.

comment:10 by stoecker, 6 years ago

farin: Probably it is not clear to you: The upload process changes the data set! It is not simple to keep a part of the command stack, but rather all the commands (in core and plugins) you want to keep have to be checked and modified so they can cope with the new state. That's a very complicated task and has nearly no benefit. That's why it is a WONTFIX.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.