Project

General

Profile

bug #6380

typedesignations missing in homotypic group

Added by Andreas Kohlbecker over 2 years ago. Updated about 1 month ago.

Status:
Closed
Priority:
Highest
Category:
cdm-dataportal
Target version:
Start date:
01/24/2017
Due date:
% Done:

100%

Severity:
normal
Found in Version:

Description

This issue seems to occur only in special cases but point out a general problem with the way the typedesignations are collected for a homotypic group.
This problem may also account to heterotypic groups.
In the homotypic group of Youngia atripappa (http://cichorieae.e-taxonomy.net/portal/cdm_dataportal/taxon/a67fc2ab-1452-4c32-84b6-8953111af9d6/synonymy) typedesignations are distributed between several names:

  • Youngia atripappa : 1 isolectotype
  • Crepis gracilis: 1 Lectotype
  • Crepis atripappa: 1 isolectotype
  • Youngia gracilis: 1 isolectotype
  • Youngia stebbinsiana: 1 isolectotype

In the portal code the typedesignatinons for the accepted taxon name and for the first name in the homotypic group after the accepted are explicitly retrieved from the portal/name/{uuid}/typeDesignations webservice.
The service and dao methods behind this service only return the typedesignations associated with the given name and are missing all others.
A solution would be to use the existing eu.etaxonomy.cdm.persistence.dao.name.IHomotypicalGroupDao.getTypeDesignations() method. For this the HomotypicalGroup uuid must be present in the portal.

TODO

  • check if this problem also accounts to heterotypic groups
  • Fix incomplete typedesignatinons retrieval

Related issues

Related to Edit - feature request #7696: use compact type representations in the synonymy as provided by the typedesignations/byTaxon/{taxon_uuid} service New 08/29/2018
Copied to Edit - feature request #8390: implement /portal/name/{uuuid}/typeDesignationsInHomotypicalGroup Closed 07/19/2019

Associated revisions

Revision b059b449 (diff)
Added by Andreas Kohlbecker about 2 months ago

fix #6380 collecting all type designations of the whole synonymy group

Revision 94a882ee (diff)
Added by Andreas Kohlbecker about 2 months ago

ref #6380 fixing regression

Revision 5f188298 (diff)
Added by Andreas Kohlbecker about 2 months ago

ref #6380 proper de-duplication of type designations

History

#1 Updated by Andreas Kohlbecker over 2 years ago

  • Description updated (diff)

#2 Updated by Andreas Kohlbecker over 2 years ago

  • Priority changed from New to Highest
  • Target version changed from Unassigned CDM tickets to Release 4.6

#3 Updated by Andreas Müller over 2 years ago

  • Description updated (diff)

#4 Updated by Andreas Müller over 2 years ago

  • Found in Version set to Release 4.5

#5 Updated by Andreas Müller over 2 years ago

  • Description updated (diff)

#6 Updated by Andreas Müller over 2 years ago

  • Description updated (diff)

#7 Updated by Andreas Müller over 2 years ago

A solution would be to use the existing >eu.etaxonomy.cdm.persistence.dao.name.IHomotypicalGroupDao.getTypeDesignations() eu.etaxonomy.cdm.persistence.dao.name.IHomotypicalGroupDao.getTypeDesignations() method. For
this this the HomotypicalGroup uuid must be present in the portal.

Another solution is * check if this problem also accounts to add a parameter "forAllNamesInHomotypicGroup" and still pass only the first name to the method in remote and service layer.

#8 Updated by Andreas Müller over 2 years ago

  • Description updated (diff)

#9 Updated by Andreas Müller over 2 years ago

  • Target version changed from Release 4.6 to Release 4.7

#10 Updated by Andreas Müller over 2 years ago

  • Target version changed from Release 4.7 to Release 4.8

#11 Updated by Andreas Kohlbecker about 2 years ago

  • Target version changed from Release 4.8 to Release 4.9

#12 Updated by Andreas Müller about 2 years ago

  • Target version changed from Release 4.9 to Release 4.10

#13 Updated by Andreas Müller almost 2 years ago

  • Target version changed from Release 4.10 to Release 4.11

#14 Updated by Andreas Müller almost 2 years ago

  • Target version changed from Release 4.11 to Release 4.12

#15 Updated by Andreas Müller over 1 year ago

  • Target version changed from Release 4.12 to Release 4.13

#16 Updated by Andreas Müller over 1 year ago

  • Target version changed from Release 4.13 to Release 4.14

#17 Updated by Andreas Müller over 1 year ago

  • Target version changed from Release 4.14 to Release 5.0

#18 Updated by Andreas Kohlbecker over 1 year ago

  • Target version changed from Release 5.0 to Release 5.1

#19 Updated by Andreas Müller about 1 year ago

  • Target version changed from Release 5.1 to Release 5.2

#20 Updated by Andreas Kohlbecker about 1 year ago

  • Target version changed from Release 5.2 to Release 5.3

#21 Updated by Andreas Kohlbecker 12 months ago

  • Target version changed from Release 5.3 to Release 5.4

#22 Updated by Andreas Kohlbecker 10 months ago

  • Target version changed from Release 5.4 to Release 5.5

#23 Updated by Andreas Kohlbecker 7 months ago

  • Target version changed from Release 5.5 to Release 5.6

#24 Updated by Andreas Kohlbecker 6 months ago

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

#25 Updated by Andreas Müller 6 months ago

  • Related to feature request #7696: use compact type representations in the synonymy as provided by the typedesignations/byTaxon/{taxon_uuid} service added

#26 Updated by Andreas Müller 6 months ago

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

Is this still a relevant issue once #7696 is fixed. As the later is on 5.6 I also moved this back. If we decide to implement we may move it elsewhere (or close it as irrelevant)

#27 Updated by Andreas Kohlbecker 4 months ago

  • Target version changed from Release 5.6 to Release 5.7

#28 Updated by Andreas Müller 4 months ago

  • Target version changed from Release 5.7 to Release 5.8

#29 Updated by Andreas Kohlbecker about 2 months ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 50

#30 Updated by Andreas Kohlbecker about 2 months ago

  • Assignee changed from Andreas Kohlbecker to Andreas Müller

#31 Updated by Andreas Müller about 1 month ago

  • Description updated (diff)

#32 Updated by Andreas Müller about 1 month ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Andreas Kohlbecker
  • % Done changed from 50 to 90

The result seems to be correct. Do I understand the code correctly that you only call 1 webservice per homotypical group to define the list of typedesignations? Otherwise it would be a performance issue.

However, I forgot why we do not yet use the results of the TypeDesignationManager in the dataportals. This formats the type designations much more as expected with less redundancy for field unit information. But this may come in future.

#33 Updated by Andreas Kohlbecker about 1 month ago

  • Assignee changed from Andreas Kohlbecker to Andreas Müller

Andreas Müller wrote:

The result seems to be correct. Do I understand the code correctly that you only call 1 webservice per homotypical group to define the list of typedesignations? Otherwise it would be a performance issue.

The type_designations_for_synonymy_group($synonymy_group, $accepted_taxon_name_uuid = null) is doing a call per name in the group. This is of course causing an undesired overhead.

However, I forgot why we do not yet use the results of the TypeDesignationManager in the dataportals. This formats the type designations much more as expected with less redundancy for field unit information. But this may come in future.

We in deed thought about this, decided to go that way and there are also according tickets which can be found by taking a look at #7695
Once this is completely solved the above mentioned overhead will be avoided.

#34 Updated by Andreas Müller about 1 month ago

  • Assignee changed from Andreas Müller to Andreas Kohlbecker

Until then why can't we use a ws call that collects all type designations of a single name in the homotypic group for all names in this group as also suggested above in the ticket.
But spending time on this only makes sense if usage of TypeDesignationManager will still take some time.

#35 Updated by Andreas Kohlbecker about 1 month ago

Andreas Müller wrote:

Until then why can't we use a ws call that collects all type designations of a single name in the homotypic group for all names in this group as also suggested above in the ticket.
But spending time on this only makes sense if usage of TypeDesignationManager will still take some time.

Extending the NamePortalController.doGetTypeDesignations() as suggested above in comment 7 would be a real improvement.
I can't give an estimate when the implementation of the TypeDesignationManager Webservice etc (#7695) will be completed, therefore it would make sense to work on the extension of the NamePortalController.doGetTypeDesignations() by adding the suggested parameter or by adding another service endpoint. Will create a ticket for this .... #8390

#36 Updated by Andreas Kohlbecker about 1 month ago

  • Copied to feature request #8390: implement /portal/name/{uuuid}/typeDesignationsInHomotypicalGroup added

#37 Updated by Andreas Kohlbecker about 1 month ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)