bug #6380
closedtypedesignations missing in homotypic group
100%
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
Updated by Andreas Kohlbecker about 7 years ago
- Priority changed from New to Highest
- Target version changed from Unassigned CDM tickets to Release 4.6
Updated by Andreas Müller about 7 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.
Updated by Andreas Müller about 7 years ago
- Target version changed from Release 4.6 to Release 4.7
Updated by Andreas Müller almost 7 years ago
- Target version changed from Release 4.7 to Release 4.8
Updated by Andreas Kohlbecker almost 7 years ago
- Target version changed from Release 4.8 to Release 4.9
Updated by Andreas Müller over 6 years ago
- Target version changed from Release 4.9 to Release 4.10
Updated by Andreas Müller over 6 years ago
- Target version changed from Release 4.10 to Release 4.11
Updated by Andreas Müller over 6 years ago
- Target version changed from Release 4.11 to Release 4.12
Updated by Andreas Müller over 6 years ago
- Target version changed from Release 4.12 to Release 4.13
Updated by Andreas Müller about 6 years ago
- Target version changed from Release 4.13 to Release 4.14
Updated by Andreas Müller about 6 years ago
- Target version changed from Release 4.14 to Release 5.0
Updated by Andreas Kohlbecker almost 6 years ago
- Target version changed from Release 5.0 to Release 5.1
Updated by Andreas Müller almost 6 years ago
- Target version changed from Release 5.1 to Release 5.2
Updated by Andreas Kohlbecker over 5 years ago
- Target version changed from Release 5.2 to Release 5.3
Updated by Andreas Kohlbecker over 5 years ago
- Target version changed from Release 5.3 to Release 5.4
Updated by Andreas Kohlbecker over 5 years ago
- Target version changed from Release 5.4 to Release 5.5
Updated by Andreas Kohlbecker about 5 years ago
- Target version changed from Release 5.5 to Release 5.6
Updated by Andreas Kohlbecker about 5 years ago
- Target version changed from Release 5.6 to Reviewed Next Major Release
Updated by Andreas Müller about 5 years ago
- Related to feature request #7696: use compact type representations in the synonymy as provided by the typedesignations/byTaxon/{taxon_uuid} service added
Updated by Andreas Müller about 5 years 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)
Updated by Andreas Kohlbecker about 5 years ago
- Target version changed from Release 5.6 to Release 5.7
Updated by Andreas Müller almost 5 years ago
- Target version changed from Release 5.7 to Release 5.8
Updated by Andreas Kohlbecker almost 5 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 50
Applied in changeset cdm-dataportal|b059b449f976cd7e198a3e21c05e38fb038ba1eb.
Updated by Andreas Kohlbecker almost 5 years ago
- Assignee changed from Andreas Kohlbecker to Andreas Müller
please review, e.g. at the example of http://test.e-taxonomy.eu/dataportal/preview/cichorieae/cdm_dataportal/taxon/a67fc2ab-1452-4c32-84b6-8953111af9d6/synonymy
Updated by Andreas Müller over 4 years 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.
Updated by Andreas Kohlbecker over 4 years 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.
Updated by Andreas Müller over 4 years 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.
Updated by Andreas Kohlbecker over 4 years 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
Updated by Andreas Kohlbecker over 4 years ago
- Copied to feature request #8390: implement /portal/name/{uuuid}/typeDesignationsInHomotypicalGroup added
Updated by Andreas Kohlbecker over 4 years ago
- Status changed from Feedback to Closed
- % Done changed from 90 to 100