task #9253
closed
revise OccurrenceServiceImpl.findFieldUnitDTO(..)
Added by Andreas Kohlbecker over 3 years ago.
Updated over 3 years ago.
Description
This intended function of FieldUnitDTO OccurrenceServiceImpl.findFieldUnitDTO(DerivateDTO derivedUnitDTO, Collection<FieldUnitDTO> fieldUnits, HashMap<UUID, DerivateDTO> alreadyCollectedSpecimen)
is quite unclear, not only because the documentation is missing (#8458), but also since the method is confuses reagarding the method signature: All detected fieldunits are added to the Collection<FieldUnitDTO> fieldUnits
passed as parameter but one of the field units is returned. From the description of #8423 supports the impression that this method covers two distinct functionalities at the same.
TODO:
- refactor the method to make its clarify its purpose and concerns. - DONE
- revise commented code and clean up
- remove the init strategy (first FIXME in code) - DONE
- allow for walking multiple origin paths (second FIXME in code) ---> #9430
- The methods
OccurrenceServiceImpl._findFieldUnitDTO
and OccurrenceServiceImpl.findFieldUnitDTO()
are operating on DTOs. This causes a computation overhead which could be significant in cases where intermediate derivation events exists. The creation of the DTOs is quite expensive since they are relatively complex objects for which quite some entity initialization is necessary. It would be better to do the search for field units purely on the entity level and to create DTOs in a final step only for those entities which are needed for the out put or response. ---> #9431
- Description updated (diff)
- Related to task #8458: document FieldUnitDTOOccurrenceServiceImpl.findFieldUnitDTO() added
- Related to bug #8423: OccurrenceServiceImpl.findFieldUnitDTO() fails to merge derivation paths when a FieldUnit has two derivatives added
- Related to task #9252: Harmonize SpecimenOrOberservationBase related DTOs added
- Related to task #8419: Harmonization of the different specimen representations added
- Related to bug #9257: revise filtering in OccurrenceServiceImpl.assembleFieldUnitDTO(FieldUnit fieldUnit) by SpecimenOrObservationType.PreservedSpecimen added
- % Done changed from 0 to 40
- Status changed from New to In Progress
- Description updated (diff)
there are two open FIXMEs in the method:
// FIXME defining propertyPaths inside of transactional service method makes no sense. see also #9253
propertyPaths.add("descriptions.elements.media.title");
propertyPaths.add("kindOfUnit");
propertyPaths.add("derivedFrom");
// FIXME allow handling multiple originals
SpecimenOrObservationBase<?> original = originals.get(0);
- Target version changed from Release 5.18 to Release 5.19
more TODO:
revise commented code and clean up
.. and another one:
TODO: The methods OccurrenceServiceImpl._findFieldUnitDTO
and OccurrenceServiceImpl.findFieldUnitDTO()
are operating on DTOs. This causes a computation overhead which could be significant in cases where intermediate derivation events exists. The creation of the DTOs is quite expensive since they are relatively complex objects for which quite some entity initialization is necessary. It would be better to do the search for field units purely on the entity level and to create DTOs in a final step only for those entities which are needed for the out put or response.
- Description updated (diff)
updating description with latest TODOs
- Related to feature request #7704: Dataportal specimen table should be able to show DerivedUnits without a FieldUnit added
- Status changed from In Progress to Resolved
- Copied to task #9430: revise OccurrenceServiceImpl._findRootUnitDTO(..) supports multiple origin paths added
- Description updated (diff)
- Copied to task #9431: OccurrenceServiceImpl._findRootUnitDTO(..) added
- Description updated (diff)
- Status changed from Resolved to Closed
- % Done changed from 40 to 100
- Related to bug #9556: occurrence/{uuid}/fieldUnitDTOs web service adds duplicate units to response added
Also available in: Atom
PDF