Project

General

Profile

Actions

task #7515

open

TypeDesignationStatusComparator to sort by vocabulary first and then by term order

Added by Andreas Kohlbecker over 4 years ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Highest
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

70%

Estimated time:
Severity:
normal

Description

I stumbled over this when editing possibly invalid data with the Taxeditor:

Opening the "Details View" for a name in the "Name Bulk Editor" causes an IllegalStateException when the name is associated with specimen types and name types at the same time:

login : admin
editor version : 5.1.0.201806251348
server : localhost (localhost-dev)
schema version : 5.0.0.0.20180514
os : Linux 4.13.0-45-generic amd64
java : 1.8.0_131
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.IllegalStateException: 2 terms do not belong to the same vocabulary and therefore can not be compared: Epitype and lectotype)
    at org.eclipse.swt.SWT.error(SWT.java:4533)
    at org.eclipse.swt.SWT.error(SWT.java:4448)
    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185)
    at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4536)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4154)
    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)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
Caused by: java.lang.IllegalStateException: 2 terms do not belong to the same vocabulary and therefore can not be compared: Epitype and lectotype
    at eu.etaxonomy.cdm.model.common.OrderedTermBase.performCompareTo(OrderedTermBase.java:131)
    at eu.etaxonomy.cdm.model.common.OrderedTermBase.compareTo(OrderedTermBase.java:103)
    at eu.etaxonomy.cdm.api.service.name.TypeDesignationStatusComparator.compare(TypeDesignationStatusComparator.java:35)
    at eu.etaxonomy.cdm.api.service.name.TypeDesignationComparator.compare(TypeDesignationComparator.java:39)
    at eu.etaxonomy.cdm.api.service.name.TypeDesignationComparator.compare(TypeDesignationComparator.java:20)
    at java.util.TimSort.binarySort(TimSort.java:296)
    at java.util.TimSort.sort(TimSort.java:221)
    at java.util.Arrays.sort(Arrays.java:1512)
    at java.util.ArrayList.sort(ArrayList.java:1454)
    at java.util.Collections.sort(Collections.java:175)
    at eu.etaxonomy.taxeditor.ui.section.AbstractEntityCollectionSection.renderContent(AbstractEntityCollectionSection.java:225)
    at eu.etaxonomy.taxeditor.ui.section.AbstractEntityCollectionSection.internalUpdateSection(AbstractEntityCollectionSection.java:207)
    at eu.etaxonomy.taxeditor.ui.section.AbstractEntityCollectionSection.setEntity(AbstractEntityCollectionSection.java:165)
    at eu.etaxonomy.taxeditor.view.detail.CdmSectionPart.setFormInput(CdmSectionPart.java:155)
    at org.eclipse.ui.forms.ManagedForm.setInput(ManagedForm.java:210)
    at eu.etaxonomy.taxeditor.view.e4.AbstractCdmDataViewerE4.refresh(AbstractCdmDataViewerE4.java:161)
    at eu.etaxonomy.taxeditor.view.e4.AbstractCdmDataViewerE4.setInput(AbstractCdmDataViewerE4.java:143)
    at eu.etaxonomy.taxeditor.view.e4.details.DetailsViewerE4.setInput(DetailsViewerE4.java:194)
    at eu.etaxonomy.taxeditor.view.e4.AbstractCdmEditorPartE4.showViewer(AbstractCdmEditorPartE4.java:225)
    at eu.etaxonomy.taxeditor.view.e4.details.DetailsPartE4.selectionChanged_internal(DetailsPartE4.java:104)
    at eu.etaxonomy.taxeditor.view.e4.AbstractCdmEditorPartE4$DelaySelection.run(AbstractCdmEditorPartE4.java:85)
    at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182)
    ... 24 more

The Taxeditor should be more resilient against unusual data.

  1. Suggestion as discussed with Andreas Müller: The TypeDesignationStatusComparator should order the Terms first by the Vocabulary and secondly by term order id.
  2. The implementation of the TypeDesignationStatusComparator in principle is an OrderedTermComparator which fixes the unorthodox inverse sort order of the cdm and which can handle a NullEntity. Maybe the diversification in multiple parallel implementations can be harmonized into one base implementation which can be configured to work with all term types:

public class OrderedTermComparator <T extends DefinedTermBase<?>> implements Comparator<T>{

    private T nullTerm;

    private canonicalSortOrder = true;

    /**
     * {@inheritDoc}
     */
    @Override
    public int compare(T o1, T o2) {
      ...
    }

    // getters and setters

}


Related issues

Related to EDIT - feature request #6794: Improve term structureIn ProgressAndreas Müller

Actions
Related to EDIT - feature request #7234: Make areas in TaxEditor distribution editor sortableClosedKatja Luther

Actions
Actions #1

Updated by Andreas Müller over 4 years ago

  • Target version changed from Release 5.2 to Release 5.3
Actions #2

Updated by Katja Luther over 4 years ago

  • Target version changed from Release 5.3 to Release 5.4
Actions #3

Updated by Andreas Müller over 4 years ago

  • Target version changed from Release 5.4 to Release 5.5
Actions #4

Updated by Andreas Müller almost 4 years ago

  • Target version changed from Release 5.5 to Release 5.6
Actions #5

Updated by Katja Luther almost 4 years ago

  • Priority changed from New to Highest
Actions #6

Updated by Andreas Müller almost 4 years ago

We may also include the upcoming new term structure (using TermCollections) #6794.

Actions #7

Updated by Andreas Müller almost 4 years ago

Actions #8

Updated by Katja Luther almost 4 years ago

Andreas Kohlbecker wrote:

The Taxeditor should be more resilient against unusual data.

  1. Suggestion as discussed with Andreas Müller: The TypeDesignationStatusComparator should order the Terms first by the Vocabulary and secondly by term order id.

This is already implemented in OrderTermComparator, so if TypeDesinationStatusComparator inherit from it the ordering should be like described above.

Actions #9

Updated by Katja Luther almost 4 years ago

Actions #10

Updated by Katja Luther almost 4 years ago

now TypeDesignationStatusComparator inherit from OrderedTermBaseComparator

Actions #11

Updated by Katja Luther almost 4 years ago

  • Status changed from New to In Progress
Actions #12

Updated by Katja Luther almost 4 years ago

  • Assignee changed from Katja Luther to Andreas Müller

please have a look whether this solves the problem

Actions #13

Updated by Andreas Müller almost 4 years ago

  • Status changed from In Progress to Resolved
Actions #14

Updated by Andreas Müller about 2 months ago

  • % Done changed from 0 to 70
Actions

Also available in: Atom PDF