feature request #7463
closedMove taxonnodes should be available for multiple selection
Added by Katja Luther almost 6 years ago. Updated almost 6 years ago.
100%
Description
Open issues:
Don't move (grand)child nodes of selected parents to the top level.- Exception in #7463#note-6
- refresh after task end #7463#note-8
- report (e.g. count of moved nodes)
- (progress monitor shows correct percentage) ...
exclude move with new parent = old parent
Related issues
Updated by Katja Luther almost 6 years ago
at the moment moving taxon node is only available for a single node, we should provide it also for a set of nodes.
Updated by Katja Luther almost 6 years ago
- Tracker changed from bug to feature request
Updated by Katja Luther almost 6 years ago
- Related to feature request #7464: make move Taxonnodes a longrunning task added
Updated by Katja Luther almost 6 years ago
- Status changed from New to Resolved
- Assignee changed from Katja Luther to Andreas Müller
please review
Updated by Andreas Müller almost 6 years ago
- Status changed from Resolved to Feedback
- Assignee changed from Andreas Müller to Katja Luther
While testing I got the following exception:
login : admin
editor version : 5.1.0.201806142059
server : test.e-taxonomy.eu (edit-test) / rem_conf_am
schema version : 5.0.0.0.20180514
os : Windows Server 2012 R2 6.3 amd64
java : 1.8.0_121
org.springframework.remoting.RemoteAccessException: Could not access HTTP invoker remote service at [http://test.e-taxonomy.eu:80/cdmserver/rem_conf_am/remoting/progressmonitor.service]; nested exception is java.io.EOFException
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.convertHttpInvokerAccessException(HttpInvokerClientInterceptor.java:216)
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:147)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
at com.sun.proxy.$Proxy53.getRemotingMonitor(Unknown Source)
at eu.etaxonomy.taxeditor.model.AbstractUtility.executeMoniteredOperation(AbstractUtility.java:681)
at eu.etaxonomy.taxeditor.navigation.navigator.e4.TreeNodeDropAdapterE4$1.run(TreeNodeDropAdapterE4.java:230)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4211)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3827)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1121)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1022)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:150)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:693)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:610)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
at eu.etaxonomy.taxeditor.Application.start(Application.java:24)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
Caused by: java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2903)
at java.io.ObjectInputStream.skipCustomData(ObjectInputStream.java:2185)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2159)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:422)
at java.util.ArrayList.readObject(ArrayList.java:791)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2122)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:422)
at java.util.ArrayList.readObject(ArrayList.java:791)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2122)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:422)
at java.util.HashSet.readObject(HashSet.java:333)
at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2122)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2231)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2155)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2013)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:422)
at org.springframework.remoting.httpinvoker.AbstractHttpInvokerRequestExecutor.doReadRemoteInvocationResult(AbstractHttpInvokerRequestExecutor.java:292)
at org.springframework.remoting.httpinvoker.AbstractHttpInvokerRequestExecutor.readRemoteInvocationResult(AbstractHttpInvokerRequestExecutor.java:243)
at org.springframework.remoting.httpinvoker.HttpComponentsHttpInvokerRequestExecutor.doExecuteRequest(HttpComponentsHttpInvokerRequestExecutor.java:232)
at org.springframework.remoting.httpinvoker.AbstractHttpInvokerRequestExecutor.executeRequest(AbstractHttpInvokerRequestExecutor.java:138)
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.java:194)
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.executeRequest(HttpInvokerClientInterceptor.java:176)
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:144)
... 30 more
Updated by Andreas Müller almost 6 years ago
Andreas Müller wrote:
While testing I got the following exception:
... happend only once, usually it seems to work, but maybe the stacktrace gives a hint?
Updated by Andreas Müller almost 6 years ago
The tree does not correctly update after the task finished.
Updated by Andreas Müller almost 6 years ago
I never got percentage > 0%. Also the "Updated Objects seem not to be clear. It usually shows the number of nodes moved + 2.
Updated by Andreas Müller almost 6 years ago
Critical: when moving a taxon and its children (selected because the subtree was open) I would expect that the subtree structure ist kept but it is not.
The taxa are added to the new parent all as direct children, loosing there own internal parent child relationship.
Updated by Katja Luther almost 6 years ago
Andreas Müller wrote:
Critical: when moving a taxon and its children (selected because the subtree was open) I would expect that the subtree structure ist kept but it is not.
The taxa are added to the new parent all as direct children, loosing there own internal parent child relationship.
if you select only the parent the parent child relationship is kept. But if you select parent and children they all are moved to the new parent.
Updated by Katja Luther almost 6 years ago
Andreas Müller wrote:
I never got percentage > 0%. Also the "Updated Objects seem not to be clear. It usually shows the number of nodes moved + 2.
this is because the new and the old parents are updated, too.
Updated by Katja Luther almost 6 years ago
Andreas Müller wrote:
The tree does not correctly update after the task finished.
This seems to be the case, when there is an exception and the longrunning task is still running. -> we have to find a solution for catching the exception
normally the update works correctly.
I currently don't know why, but the handling of the RemotingProgressMonitor (especially the call of progressMonitorService.getRemotingMonitor(uuid);) takes a lot of time, so, the task of moving nodes is already completed when the first poll for the monitorthread is done and therefore the percentage keep the 0% till the first poll and then the task is already completed.
This is something we have to work on!
Updated by Andreas Müller almost 6 years ago
- Subject changed from move taxonnodes should be available for multiple selection to Move taxonnodes should be available for multiple selection
- Description updated (diff)
Katja Luther wrote:
Andreas Müller wrote:
Critical: when moving a taxon and its children (selected because the subtree was open) I would expect that the subtree structure ist kept but it is not.
The taxa are added to the new parent all as direct children, loosing there own internal parent child relationship.
if you select only the parent the parent child relationship is kept. But if you select parent and children they all are moved to the new parent.
Yes, I know, but the question is, how to improve this. The current situation may lead to unwanted data changes just because users don't know/understand this behavior.
I would suggest to add something to the algorithm to check if a node which is within the multiselect has a parent/grandparent which is also selected. If yes, we should not add it to the "move"-operation. Is this easy to check? Easiest would be to use the treeindex. Is it available in the navigator? Or do we need a service layer method to collect all the "root" nodes for a given set of selected nodes?
Updated by Katja Luther almost 6 years ago
Andreas Müller wrote:
Katja Luther wrote:
Andreas Müller wrote:
Critical: when moving a taxon and its children (selected because the subtree was open) I would expect that the subtree structure ist kept but it is not.
The taxa are added to the new parent all as direct children, loosing there own internal parent child relationship.
if you select only the parent the parent child relationship is kept. But if you select parent and children they all are moved to the new parent.
Yes, I know, but the question is, how to improve this. The current situation may lead to unwanted data changes just because users don't know/understand this behavior.
I would suggest to add something to the algorithm to check if a node which is within the multiselect has a parent/grandparent which is also selected. If yes, we should not add it to the "move"-operation. Is this easy to check? Easiest would be to use the treeindex. Is it available in the navigator? Or do we need a service layer method to collect all the "root" nodes for a given set of selected nodes?
I don't know, if this is the expected behaviour. If I select a node to move it as a child to another node I would expect that the node moves to this new parent independent of its former parent.
But we can check whether one of the nodes is the parent of the other nodes, we have the treeindex available in the navigator.
Updated by Andreas Müller almost 6 years ago
- Description updated (diff)
Katja Luther wrote:
Andreas Müller wrote:
I never got percentage > 0%. Also the "Updated Objects seem not to be clear. It usually shows the number of nodes moved + 2.
this is because the new and the old parents are updated, too.
But in general the children and grand children are also somehow changed (at least the treeindex). The question is if we also want to include this information. Maybe we could also adapt the report into something like "x taxa moved" instead of "x objects changed". Easier to read for the user. Also we could split the information and say "x taxa have been moved with y children attached".
Updated by Andreas Müller almost 6 years ago
Katja Luther wrote:
Andreas Müller wrote:
Katja Luther wrote:
Andreas Müller wrote:
Critical: when moving a taxon and its children (selected because the subtree was open) I would expect that the subtree structure ist kept but it is not.
The taxa are added to the new parent all as direct children, loosing there own internal parent child relationship.
if you select only the parent the parent child relationship is kept. But if you select parent and children they all are moved to the new parent.
Yes, I know, but the question is, how to improve this. The current situation may lead to unwanted data changes just because users don't know/understand this behavior.
I would suggest to add something to the algorithm to check if a node which is within the multiselect has a parent/grandparent which is also selected. If yes, we should not add it to the "move"-operation. Is this easy to check? Easiest would be to use the treeindex. Is it available in the navigator? Or do we need a service layer method to collect all the "root" nodes for a given set of selected nodes?I don't know, if this is the expected behaviour. If I select a node to move it as a child to another node I would expect that the node moves to this new parent independent of its former parent.
But we can check whether one of the nodes is the parent of the other nodes, we have the treeindex available in the navigator.
It is true, that you may not know what is expected. But there is at least one dangerous usecase. The user selects a number of 100 taxa to move them all by selecting the first and the last taxon. He/she may not realize that these taxa have expanded childnodes. But the multiselect automatically also selects the child nodes if they are expanded. So the tree structure may change without the user realizing it.
What about checking for children in the selection and if there are children asking the user via dialog how to handle the "conflict". As selecting children on purpose is expected to be a rare case this may not often interrupt the workflow.
Updated by Andreas Müller almost 6 years ago
By the way, performance is surprisingly good. Moving hundreds of taxa takes only 2-3 sec, even if most of them are root taxa.
Only problem with selecting many root taxa that the UI becomes somehow unresponsive between drag and drop (and after drop if already before unresponsive).
Probably this is an eclipse issue of the tree navigator?
Updated by Andreas Müller almost 6 years ago
- Description updated (diff)
We may also check, if the new parent node is already the old parent node. These nodes should not be moved (not critical as nothing wrong happens, but better for performance, and also the reporting is more correct then)
Updated by Andreas Müller almost 6 years ago
Andreas Müller wrote:
While testing I got the following exception:
login : admin editor version : 5.1.0.201806142059 server : test.e-taxonomy.eu (edit-test) / rem_conf_am schema version : 5.0.0.0.20180514 os : Windows Server 2012 R2 6.3 amd64 java : 1.8.0_121 org.springframework.remoting.RemoteAccessException: Could not access HTTP invoker remote service at [http://test.e-taxonomy.eu:80/cdmserver/rem_conf_am/remoting/progressmonitor.service]; nested exception is java.io.EOFException at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.convertHttpInvokerAccessException(HttpInvokerClientInterceptor.java:216) at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:147) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
same happened at #6321#note-13
Updated by Andreas Müller almost 6 years ago
- Related to feature request #6321: Implement parallel loading + progress bar for loading objects into the bulk editor added
Updated by Katja Luther almost 6 years ago
Katja Luther wrote:
Open issues:
- Don't move (grand)child nodes of selected parents to the top level.
- Exception in #7463#note-6
- refresh after task end #7463#note-8
- report (e.g. count of moved nodes)
- (progress monitor shows correct percentage) ...
- exclude move with new parent = old parent
- the count of the report only contains the moved nodes.
- children are kept as children of a moved parent
- drag & drop to same parent is not allowed
Updated by Katja Luther almost 6 years ago
in classification combo, the classification of the first selected node is preselected, now.
Updated by Andreas Müller almost 6 years ago
- Description updated (diff)
The refresh issue still exists and is critical. It seems to happen with large subtrees. E.g. I moved Charyophyllaceae Juss. with all its >>100 children from 1 classification to another. This took some time (percentage was at 100 for longer time before the job really finished, so we should also work on the percentage computation, 100% should not be reached before the save has really finished - save takes long because many tree indexes need to be recomputed).
Using refresh from menu did also not work. Only reopening navigator did solve the problem.
Updated by Andreas Müller almost 6 years ago
- Severity changed from normal to major
Updated by Andreas Müller almost 6 years ago
By the way, moving the 4 children of Charyophyllaceae Juss. results in relativ fast counting 25, 50, 75 and 100% and the 100% then waits for much longer time. This also looks like the commit/save itself which maybe takes place at the service layer border as a "hidden" process is not really taken into account. Maybe we could duplicate the number of steps, so moving takes altogether 50% and only after the final commit we add the other 50%.
Also the subtasks have no name. We could have something like "Move taxon x" where x is either a taxon name or, if not available the number 1/4, 2/4 ... The final task can then be called e.g. "Saving and recomputing index".
Updated by Katja Luther almost 6 years ago
Andreas Müller wrote:
By the way, moving the 4 children of Charyophyllaceae Juss. results in relativ fast counting 25, 50, 75 and 100% and the 100% then waits for much longer time. This also looks like the commit/save itself which maybe takes place at the service layer border as a "hidden" process is not really taken into account. Maybe we could duplicate the number of steps, so moving takes altogether 50% and only after the final commit we add the other 50%.
Also the subtasks have no name. We could have something like "Move taxon x" where x is either a taxon name or, if not available the number 1/4, 2/4 ... The final task can then be called e.g. "Saving and recomputing index".
The "problem" is that the move taxon x tasks are really fast and the saving and reindexing is the time consuming task, so I think it is not necessary to create a subtask for every taxonnode. Now I doubled the number of worksteps and added a subtask for the saving.
I also adapted the progress monitor on the editor side, and now the display in the status line should be the same as in the progress view.
Updated by Katja Luther almost 6 years ago
- Status changed from Feedback to Resolved
- Assignee changed from Katja Luther to Andreas Müller
now there are two subtasks: moving taxa and saving/reindexing, showing more subtasks are not really possible. please review
Updated by Andreas Müller almost 6 years ago
- Status changed from Resolved to Feedback
- Assignee changed from Andreas Müller to Katja Luther
Andreas Müller wrote:
The refresh issue still exists and is critical. It seems to happen with large subtrees. E.g. I moved Charyophyllaceae Juss. with all its >>100 children from 1 classification to another. This took some time (percentage was at 100 for longer time before the job really finished, so we should also work on the percentage computation, 100% should not be reached before the save has really finished - save takes long because many tree indexes need to be recomputed).
Using refresh from menu did also not work. Only reopening navigator did solve the problem.
This still happens though it does not happen always. Once the tree is opened at both places it does not happen but at beginning it may happen.
All the rest seems to work fine.
Updated by Katja Luther almost 6 years ago
- % Done changed from 50 to 100
we have to have a look why the refresh sometimes does not work, therefore I create a new ticket and close this one (see #7521)
Updated by Katja Luther almost 6 years ago
- Status changed from Feedback to Closed
Updated by Katja Luther almost 6 years ago
- Related to bug #7521: refresh of taxonnavigator sometimes does not work for moving taxonnodes added