Project

General

Profile

Actions

bug #5639

open

NPE when showing name relationships for a name originally related to a deleted name

Added by Andreas Müller about 7 years ago. Updated about 4 years ago.

Status:
In Progress
Priority:
Highest
Assignee:
Category:
taxeditor
Start date:
Due date:
% Done:

0%

Estimated time:
2:00 h
Severity:
normal
Found in Version:

Description

I deleted a name from Cuba Checklist (id = 2949).

Afterwards I tried to show the name relationships for Chloris barbata (L.) Nash and got the following error:

Maybe this is not reproducable easily because it is related to data cached in the editor. As far as I remember there was no direct name relationship between these 2 names.

It only happened in the bulk editor, not in the name editor.

login : admin
editor version : 3.12.4
server : api.cybertaxonomy.org / cybertaxonomy.org
schema version : 3.6.0.0.201527040000
os : Windows Server 2012 6.2 amd64
java : 1.7.0_75
java.lang.NullPointerException: CDM Entity of type eu.etaxonomy.cdm.model.name.TaxonNameBase with id 2949 is null.
    at eu.etaxonomy.taxeditor.service.CachedCommonServiceImpl.find(CachedCommonServiceImpl.java:48)
    at org.hibernate.proxy.AbstractLazyInitializer.remoteInitialize(AbstractLazyInitializer.java:449)
    at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:167)
    at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:295)
    at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:185)
    at eu.etaxonomy.cdm.model.name.TaxonNameBase_$$_javassist_6.getTitleCache(TaxonNameBase_$$_javassist_6.java)
    at eu.etaxonomy.taxeditor.ui.section.name.NameRelationshipDetailElement.setEntity(NameRelationshipDetailElement.java:74)
    at eu.etaxonomy.taxeditor.ui.section.name.NameRelationshipDetailElement.setEntity(NameRelationshipDetailElement.java:1)
    at eu.etaxonomy.taxeditor.ui.section.supplemental.AbstractReferencedEntityElement.setEntity(AbstractReferencedEntityElement.java:1)
    at eu.etaxonomy.taxeditor.ui.section.AbstractEntityCollectionElement.<init>(AbstractEntityCollectionElement.java:137)
    at eu.etaxonomy.taxeditor.ui.section.AbstractEntityCollectionElement.<init>(AbstractEntityCollectionElement.java:68)
    at eu.etaxonomy.taxeditor.ui.section.supplemental.AbstractReferencedEntityElement.<init>(AbstractReferencedEntityElement.java:39)
    at eu.etaxonomy.taxeditor.ui.section.name.NameRelationshipDetailElement.<init>(NameRelationshipDetailElement.java:55)
    at eu.etaxonomy.taxeditor.ui.element.CdmFormFactory.createEntityCollectionElement(CdmFormFactory.java:2508)
    at eu.etaxonomy.taxeditor.ui.section.AbstractEntityCollectionSection.createElementComposite(AbstractEntityCollectionSection.java:234)
    at eu.etaxonomy.taxeditor.ui.section.AbstractEntityCollectionSection.createDynamicContents(AbstractEntityCollectionSection.java:222)
    at eu.etaxonomy.taxeditor.ui.section.AbstractEntityCollectionSection.renderContent(AbstractEntityCollectionSection.java:191)
    at eu.etaxonomy.taxeditor.ui.section.AbstractEntityCollectionSection.expansionStateChanged(AbstractEntityCollectionSection.java:276)
    at org.eclipse.ui.forms.widgets.ExpandableComposite.fireExpanding(ExpandableComposite.java:1081)
    at org.eclipse.ui.forms.widgets.ExpandableComposite.toggleState(ExpandableComposite.java:1065)
    at org.eclipse.ui.forms.widgets.ExpandableComposite.access$5(ExpandableComposite.java:1061)
    at org.eclipse.ui.forms.widgets.ExpandableComposite$2.linkActivated(ExpandableComposite.java:576)
    at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleActivate(AbstractHyperlink.java:233)
    at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleMouseUp(AbstractHyperlink.java:327)
    at org.eclipse.ui.forms.widgets.AbstractHyperlink.access$2(AbstractHyperlink.java:311)
    at org.eclipse.ui.forms.widgets.AbstractHyperlink$4.handleEvent(AbstractHyperlink.java:125)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
    at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4165)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3754)
    at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
    at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
    at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
    at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
    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:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
Actions #1

Updated by Andreas Müller about 7 years ago

  • Target version changed from Unassigned CDM tickets to Release 4.0
  • Priority changed from New to Priority14
Actions #2

Updated by Andreas Müller almost 7 years ago

  • Target version changed from Release 4.0 to Release 4.1
Actions #3

Updated by Andreas Müller almost 7 years ago

  • Target version changed from Release 4.1 to Release 4.2
Actions #4

Updated by Andreas Müller over 6 years ago

  • Target version changed from Release 4.2 to Release 4.3
Actions #5

Updated by Andreas Müller over 6 years ago

  • Target version changed from Release 4.3 to Release 4.4
Actions #6

Updated by Andreas Müller over 6 years ago

  • Description updated (diff)
  • Priority changed from Priority14 to Highest
  • Estimated time set to 2:00 h
Actions #7

Updated by Andreas Müller over 6 years ago

  • Target version changed from Release 4.4 to Release 4.5
Actions #8

Updated by Andreas Müller about 6 years ago

  • Target version changed from Release 4.5 to Release 4.6
Actions #9

Updated by Katja Luther about 6 years ago

I could reproduce it with following settings:

name1 has nameRelation to name2 and name2 has another nameRelation to name3 which I deleted in DB.
Search for name1 in bulk editor and click on namerelationships -> Exception
This is because the second nameRelation of name2 points to a name that does not exist anymore. This is a problem of corrupted data and so the error message is correct. Maybe we can show a better message dialog to the user.

Actions #10

Updated by Andreas Müller about 6 years ago

Katja Luther wrote:

I could reproduce it with following settings:

name1 has nameRelation to name2 and name2 has another nameRelation to name3 which I deleted in DB.
Search for name1 in bulk editor and click on namerelationships -> Exception
This is because the second nameRelation of name2 points to a name that does not exist anymore. This is a problem of corrupted data and so the error message is correct. Maybe we can show a better message dialog to the user.

I think this should be handled a bit earlier. When deleting name3 the delete operation should have decided (via configuration, user feedback or what ever) how to handle the name relationship. If the decision was that the name relationship can be deleted (e.g. because name3 is the "to"-part in a "is basionym for" realtionship) then it should be fully deleted during deletion of name2 and therefore no error should be thrown during save of name1 or 2. If the decision was that the relationship can not be deleted than the feedback should be given during deletion of name3 and the name must not be deleted.

But maybe I misunderstand the whole setting here.

Actions #11

Updated by Andreas Müller about 6 years ago

  • Target version changed from Release 4.6 to Release 4.7
Actions #12

Updated by Andreas Müller almost 6 years ago

  • Target version changed from Release 4.7 to Release 4.8
Actions #13

Updated by Katja Luther almost 6 years ago

Andreas Müller wrote:

Katja Luther wrote:

I could reproduce it with following settings:

name1 has nameRelation to name2 and name2 has another nameRelation to name3 which I deleted in DB.
Search for name1 in bulk editor and click on namerelationships -> Exception
This is because the second nameRelation of name2 points to a name that does not exist anymore. This is a problem of corrupted data and so the error message is correct. Maybe we can show a better message dialog to the user.

I think this should be handled a bit earlier. When deleting name3 the delete operation should have decided (via configuration, user feedback or what ever) how to handle the name relationship. If the decision was that the name relationship can be deleted (e.g. because name3 is the "to"-part in a "is basionym for" realtionship) then it should be fully deleted during deletion of name2 and therefore no error should be thrown during save of name1 or 2. If the decision was that the relationship can not be deleted than the feedback should be given during deletion of name3 and the name must not be deleted.

But maybe I misunderstand the whole setting here.

But the problem was, that name3 was deleted in DB not by a delete operation of cdmlib. Normally this should not be happen. But in the description of this ticket you also said that the name was deleted in DB.

Actions #14

Updated by Andreas Müller almost 6 years ago

Katja Luther wrote:

Andreas Müller wrote:

I think this should be handled a bit earlier. When deleting name3 the delete operation should have decided (via configuration, user feedback or what ever) how to handle the name relationship. If the decision was that the name relationship can be deleted (e.g. because name3 is the "to"-part in a "is basionym for" realtionship) then it should be fully deleted during deletion of name2 and therefore no error should be thrown during save of name1 or 2. If the decision was that the relationship can not be deleted than the feedback should be given during deletion of name3 and the name must not be deleted.

But maybe I misunderstand the whole setting here.

But the problem was, that name3 was deleted in DB not by a delete operation of cdmlib. Normally this should not be happen. But in the description of this ticket you also said that the name was deleted in DB.

I did not write in the description that I deleted it directly via SQL. I probably deleted it via TaxEdtior. The editor should NEVER lead to a situation where data becomes inconsistent (I also wonder why hibernate allows this). This is only possible because we use MySQL ISAM which has not referential integrity checking. Otherwise it could not happen. However, it shows that there is probably a mistake in the way how the delete was executed or it is just a non existing (because deleted) object within an TaxEditor session.
As mentioned in the description I do not know if it is easily reproducable. We should at least play around a bit and try to reproduce.

Actions #15

Updated by Andreas Müller over 5 years ago

  • Status changed from New to In Progress
Actions #16

Updated by Katja Luther over 5 years ago

  • Target version changed from Release 4.8 to Release 4.10

as I could not reproduce it without deleting the name in the database, we have to move the ticket and try to play around to reproduce it from time to time.

Actions #17

Updated by Andreas Müller over 5 years ago

  • Target version changed from Release 4.10 to Release 4.12
Actions #18

Updated by Andreas Müller over 5 years ago

  • Target version changed from Release 4.12 to Release 4.13
Actions #19

Updated by Andreas Müller about 5 years ago

  • Private changed from Yes to No
Actions #20

Updated by Katja Luther about 5 years ago

  • Target version changed from Release 4.13 to Release 5.0
Actions #21

Updated by Katja Luther almost 5 years ago

  • Target version changed from Release 5.0 to Release 5.1
Actions #22

Updated by Katja Luther almost 5 years ago

  • Target version changed from Release 5.1 to Release 5.3
Actions #23

Updated by Katja Luther over 4 years ago

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

Updated by Andreas Müller over 4 years ago

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

Updated by Andreas Müller about 4 years ago

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

Updated by Andreas Müller about 4 years ago

  • Target version changed from Release 5.6 to Reviewed Next Major Release
Actions

Also available in: Atom PDF