Project

General

Profile

Actions

bug #1119

closed

[PARSER] Duplicate inreferences created during parsing are NOT merged when data gets saved

Added by Andreas Müller over 14 years ago. Updated about 3 years ago.

Status:
Duplicate
Priority:
Priority14
Category:
taxeditor
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Severity:
major
Found in Version:

Description

Probably Niels knows this.

Needs to be implemented if not yet done


Related issues

Related to EDIT - bug #7829: Improve deduplication of parsed names and referencesClosedAndreas Müller

Actions
Is duplicate of EDIT - feature request #9085: Improve deduplication of parsed namesClosedAndreas Müller

Actions
Actions #1

Updated by Niels Hoffmann over 14 years ago

  • Status changed from New to In Progress

No, I don't know this. Can I get a little more insight?

Actions #2

Updated by Andreas Müller over 14 years ago

What I meant is the following: if you parse a name you create a name, a nom ref some authors and may be a nom status. The nom ref may have an inref (e.g. a journal for an article). Do you check if this inref does already exist (can be matched) before you safe the name?

Actions #3

Updated by Niels Hoffmann over 14 years ago

  • Target version deleted (TaxEditor Release 2.0)

I looked into this. Implementation is postponed to after the migration to the new reference model.

Reason for this is mainly the non genericness of how to get the inReference. Every reference class has a differently named method for it which makes it firstly cumbersome to implement and secondly everything has to be redone once the new reference model is in place.

Actions #4

Updated by Niels Hoffmann about 14 years ago

InReferences are troubling.

This is what I found out so far:

  • The inReference itself does not get persisted correctly. A Journal is correctly recognized during parsing but gets persisted with cacheStrategy set to generic. DatePublished is another field that does not get persisted though it was recognized correctly during parsing. Because of this, the default match strategy does not match. We could set the fields to ignore in the match strategy, but I'd rather want to know what is happening there in the first place.

  • Duplicate resolving of the author is not taking place when checking references with inReferences. I have not found out so far what is going wrong here.

Do we have unit/integration tests that guarantee proper behavior of the matching mechanism running against references with inReferences?

Actions #5

Updated by Niels Hoffmann about 14 years ago

  • Tracker changed from task to bug

I am refiling this as a bug, because inReferences are producing duplicate references as well as duplicate authors.

Actions #6

Updated by Niels Hoffmann about 14 years ago

  • Subject changed from Check if duplicate inreferences created during parsing are merged when data get saved to Duplicate inreferences created during parsing are NOT merged when data get saved
Actions #7

Updated by Niels Hoffmann about 14 years ago

  • Subject changed from Duplicate inreferences created during parsing are NOT merged when data get saved to Duplicate inreferences created during parsing are NOT merged when data gets saved
Actions #8

Updated by Andreas Müller about 14 years ago

Replying to n.hoffmann:

InReferences are troubling.

This is what I found out so far:

  • The inReference itself does not get persisted correctly. A Journal is correctly recognized during parsing but gets persisted with cacheStrategy set to generic. DatePublished is another field that does not get persisted though it was recognized correctly during parsing. Because of this, the default match strategy does not match. We could set the fields to ignore in the match strategy, but I'd rather want to know what is happening there in the first place.

  • Duplicate resolving of the author is not taking place when checking references with inReferences. I have not found out so far what is going wrong here.

Do we have unit/integration tests that guarantee proper behavior of the matching mechanism running against references with inReferences?

Hi Niels,

habe mir gerade nochmal das Ticket genauer angeschaut und deinen Kommentar vom 25.1. richtig gelesen, wo du ja einen Teil meiner gerade gestellten Fragen bereits beantwortest.

Dennoch müsste ich auch erstmal ziemlich genau schauen, inwiefern es ein Matching Fehler ist.

In eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmGenericDaoImplTest findest du den Test findMatching. Da ist einiges abgehandelt u.a. auch DatePublished und Autoren. Du kannst ja mal schauen ob dein Fall auch abgedeckt ist.

Den Satz: "A Journal is correctly recognized during parsing but gets persisted with cacheStrategy set to generic." Verstehe ich nicht. Wie kann cacheStrategy to generic gesetzt werden?

So weit erstmal.

Gruß,

Andreas M.

Actions #9

Updated by Niels Hoffmann about 14 years ago

  • Priority changed from Priority14 to Priority11

"title" was set to @MatchMode.EQUAL_REQUIRED@. For newly created (just typed in) references with inReferences, the title for the inReference was still null and therefore did not match. Also lots of issues with the correct cache strategy.

The problem seems solved, but I will leave this ticket open until it is finally confirmed successfully fixed.

Actions #10

Updated by Niels Hoffmann almost 14 years ago

  • Status changed from In Progress to New
Actions #11

Updated by Niels Hoffmann almost 14 years ago

  • Priority changed from Priority11 to Priority08
Actions #12

Updated by Niels Hoffmann about 13 years ago

  • Priority changed from Priority08 to Highest
Actions #13

Updated by Niels Hoffmann about 13 years ago

  • Status changed from New to In Progress
Actions #14

Updated by Niels Hoffmann about 13 years ago

  • Subject changed from Duplicate inreferences created during parsing are NOT merged when data gets saved to [PARSER] Duplicate inreferences created during parsing are NOT merged when data gets saved
Actions #15

Updated by Niels Hoffmann over 12 years ago

  • Priority changed from Highest to Priority14
Actions #16

Updated by Andreas Müller over 6 years ago

  • Description updated (diff)
  • Assignee changed from Niels Hoffmann to Andreas Müller
  • Target version changed from TaxEditor Next Major Release to Release 4.11

If this is still open we should try to fix it soon.

Actions #17

Updated by Andreas Müller over 6 years ago

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

Updated by Andreas Müller about 3 years ago

  • Private changed from Yes to No
Actions #19

Updated by Andreas Müller about 3 years ago

  • Status changed from In Progress to Duplicate
  • Target version deleted (Release 4.12)

This has been fully fixed in #9085 so close this ticket as duplicate

Actions #20

Updated by Andreas Müller about 3 years ago

Actions #21

Updated by Andreas Müller about 3 years ago

  • Related to bug #7829: Improve deduplication of parsed names and references added
Actions

Also available in: Atom PDF