task #3722
closedUsing @OrderColumn does not work in trees
100%
Description
For TaxonNode trees and feature node trees we tried do use @OrderColumn annotation for automated sortindex. However this doesn't seem to work in the selfreferencing evironment of a node. Maybe the fact that null values must be allowed for the root node is one reason for it.
@OrderColumn work for Classification.rootNodes.
This seems to be fixed since hibernate 4.1.11/4.2.0. We still use 4.1.10. So maybe an upgrade is enough.
https://hibernate.atlassian.net/browse/HHH-5732
@IndexColumn does not work because not every FeatureNode has a parent. But only NotNull will solve the problem (otherwise we will need a join table
http://stackoverflow.com/questions/2956171/jpa-2-0-ordercolumn-annotation-in-hibernate-3-5
https://forum.hibernate.org/viewtopic.php?p=2392563
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4390
reading works, but writing doesn't
The reason why the automated version is better is that we need some additional when adding, removing etc. nodes (e.g. in addChild(child, index) which is not nice. However it is not critical as it works the way it is implemented now.
NOTE: remove the comments in both classes when this ticket is fixed
see also #3719, #2031, #4200
Files
Related issues
Updated by Andreas Müller about 3 years ago
- Related to task #9359: Update cdmlib, taxeditor, cdmserver etc. dependencies added
Updated by Andreas Müller over 2 years ago
- Description updated (diff)
- Target version changed from cdmlib - Old Next Major Release to Unassigned CDM tickets
Updated by Andreas Müller almost 2 years ago
- Target version changed from Unassigned CDM tickets to Release 5.32
sortIndex needs to be handled newly in hibernate5.2 so we can try to handle this ticket, too.
Updated by Andreas Müller almost 2 years ago
- Due date set to 05/27/2022
- Status changed from New to In Progress
- Start date set to 05/23/2022
- % Done changed from 0 to 20
Updated by Andreas Müller almost 2 years ago
- Related to task #8127: [Reminder] to check if Hibernate Null Value bug still exists added
Updated by Andreas Müller almost 2 years ago
- Status changed from In Progress to Resolved
- % Done changed from 20 to 50
Probably solved, still needs intensive testing and code cleanup.
Updated by Andreas Müller almost 2 years ago
- Related to task #10067: Update to hibernate 5.4 (or higher) and hibernate search 5.11 and lucene 5.5 added
Updated by Andreas Müller almost 2 years ago
- Assignee changed from Andreas Müller to Katja Luther
- % Done changed from 50 to 70
Please review.
Updated by Katja Luther almost 2 years ago
For polytomouskey nodes there are still null values, after creating a new alternativ and saving the rootnode contains three null values at the beginning of the array.
Updated by Andreas Müller almost 2 years ago
Katja Luther wrote in #note-14:
For polytomouskey nodes there are still null values, after creating a new alternativ and saving the rootnode contains three null values at the beginning of the array.
Did you also test for TaxonNodes? PolytomousKeyNodes maybe still need cleanup. I cleanup TaxonNodes already and tested a bit with TaxEditor and did not get any errors. But we definetely need more testing and also debugging like you did to verify no null values exist.
Which data did you test?
Updated by Katja Luther almost 2 years ago
Andreas Müller wrote in #note-15:
Katja Luther wrote in #note-14:
For polytomouskey nodes there are still null values, after creating a new alternativ and saving the rootnode contains three null values at the beginning of the array.
Did you also test for TaxonNodes? PolytomousKeyNodes maybe still need cleanup. I cleanup TaxonNodes already and tested a bit with TaxEditor and did not get any errors. But we definetely need more testing and also debugging like you did to verify no null values exist.
Which data did you test?
Yes TaxonNodes work as expected, I tested creation of a new node, moving and deleting a node.
I tested with local copy of caryophyllales_spp
Updated by Andreas Müller almost 2 years ago
SQL for testing persisted Polytomous Key Nodes:
SELECT pkn.id, pkn.created, nodenumber, KEY_id, parent_id, sortindex
FROM PolytomousKeyNode pkn
ORDER BY key_id, parent_id, sortindex
Updated by Andreas Müller almost 2 years ago
Term trees/nodes also seem to work. Katja, can you please double check this?
Updated by Katja Luther almost 2 years ago
Andreas Müller wrote in #note-18:
Term trees/nodes also seem to work. Katja, can you please double check this?
I tested term trees with moving nodes, creating new nodes and deleting nodes and everything works as expected.
Updated by Andreas Müller almost 2 years ago
On PolytomousKeys:
- added a fresh PK
- added a new top level node (like always) results in a sortindex 1 for this node but should be 0
- reverting this to 0 in DB, loading the key again, adding an alternative and save results in sortindexes 2 and 3 for the resulting 2 alternatives
- reverting this again to 0 and 1 in DB, loading the key, adding a further alternative and save results in sortindexes 3, 4 and 5 for the resulting 3 alternatives.
- only changing the statement for the 3rd alternative and saving again result in the following exception which seems to show that the data already has the null values in the list. Is this because the save/merge result is merged into the session or is there something wrong in the node handling it self on taxeditor side?
last remote method : https://test.e-taxonomy.eu:443/cdmserver/rem_conf_am/remoting/polytomouskey.service
last remote request client time : 2022-07-06T10:02:45.609
last remote request response header time : Wed, 06 Jul 2022 08:02:45 GMT
client error time : 2022-07-06T10:04:13.387
login : admin
editor version : 5.32.0.202207052247
server : test.e-taxonomy.eu (edit-test) / rem_conf_am
schema version : 5.29.0.0.20211122
os : Windows Server 2012 R2 6.3 amd64
java : 1.8.0_131
org.eclipse.core.runtime.AssertionFailedException: null argument:
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73)
at org.eclipse.jface.viewers.StructuredViewer.assertElementsNotNull(StructuredViewer.java:586)
at org.eclipse.jface.viewers.StructuredViewer.getRawChildren(StructuredViewer.java:1002)
at org.eclipse.jface.viewers.ColumnViewer.getRawChildren(ColumnViewer.java:701)
at org.eclipse.jface.viewers.AbstractTableViewer.getRawChildren(AbstractTableViewer.java:1037)
at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:907)
at org.eclipse.jface.viewers.StructuredViewer.getSortedChildren(StructuredViewer.java:1084)
at org.eclipse.jface.viewers.AbstractTableViewer.internalRefreshAll(AbstractTableViewer.java:666)
at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:614)
at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:606)
at org.eclipse.jface.viewers.StructuredViewer.lambda$0(StructuredViewer.java:1519)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1458)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1419)
at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1519)
at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:523)
at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1478)
at eu.etaxonomy.taxeditor.editor.key.polytomous.e4.PolytomousKeyListEditorE4.changed(PolytomousKeyListEditorE4.java:305)
at eu.etaxonomy.taxeditor.view.e4.AbstractCdmEditorPartE4.changed(AbstractCdmEditorPartE4.java:198)
at eu.etaxonomy.taxeditor.view.e4.AbstractCdmDataViewer.markViewPartDirty(AbstractCdmDataViewer.java:110)
at eu.etaxonomy.taxeditor.view.e4.details.DetailsViewerE4.markViewPartDirty(DetailsViewerE4.java:232)
at eu.etaxonomy.taxeditor.view.e4.AbstractCdmDataViewer$1.dirtyStateChanged(AbstractCdmDataViewer.java:80)
at org.eclipse.ui.forms.AbstractFormPart.markDirty(AbstractFormPart.java:93)
at eu.etaxonomy.taxeditor.view.detail.CdmSectionPart.propertyChange(CdmSectionPart.java:206)
at eu.etaxonomy.taxeditor.ui.element.AbstractCdmFormElement.firePropertyChangeEvent(AbstractCdmFormElement.java:230)
at eu.etaxonomy.taxeditor.ui.element.MultilanguageTextElement.propertyChange(MultilanguageTextElement.java:210)
at eu.etaxonomy.taxeditor.ui.element.KeyStatementElement.propertyChange(KeyStatementElement.java:96)
at eu.etaxonomy.taxeditor.ui.element.AbstractCdmFormElement.firePropertyChangeEvent(AbstractCdmFormElement.java:230)
at eu.etaxonomy.taxeditor.ui.element.TextWithLabelElement.modifyText(TextWithLabelElement.java:180)
at eu.etaxonomy.taxeditor.ui.element.LanguageStringWithLabelElement.modifyText(LanguageStringWithLabelElement.java:93)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:180)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4418)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1079)
...
Updated by Andreas Müller almost 2 years ago
- Status changed from Resolved to Feedback
- Assignee changed from Katja Luther to Andreas Müller
Updated by Andreas Müller over 1 year ago
- Status changed from Feedback to Closed
- % Done changed from 70 to 100
This ticket is more about @OrderColumn generally does not work which is not the case. The remaining issue is a NULL-Value issue related to #5536 which is more or less independent of the @OrderColumn itself. We removed the workaround created for #5536 as we hoped that the issue was solved on hibernate side (#8127, https://hibernate.atlassian.net/browse/HHH-9751), which is not the case as HHH-9751 seems to be closed only as duplicate and the ticket it duplicates https://hibernate.atlassian.net/browse/HHH-9979 is still open. And anyway it is not sure if HHH-9979 is the reason for our problem at all.
So I close this ticket and handle the issue in #8127 or a newly created ticket.
Updated by Andreas Müller over 1 year ago
- Related to bug #10101: Correct mapping and handling of sorted tree structures added