Project

General

Profile

Actions

bug #6859

open

DerivedUnitFacade.newFacadeFrom() fails when occurrenceUuid references a FieldUnit

Added by Andreas Kohlbecker over 6 years ago. Updated over 6 years ago.

Status:
New
Priority:
New
Category:
cdmlib
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Severity:
normal
Found in Version:
Actions #1

Updated by Andreas Kohlbecker over 6 years ago

Hallo Andreas, Patrick

Wir (AK + ich) hatten uns das ja vorhin angeschaut, dass Walters jetzige Bilder Fehler schmeißen.

Das liegt v.a. an der Methode


    private DerivedUnitFacade newFacadeFrom(UUID occurrenceUuid, HttpServletResponse response, List<String> extendedInitStrategy)

    throws IOException {

        List<String> initStrategy = new ArrayList<String>(initializationStrategy);

        if(extendedInitStrategy != null && extendedInitStrategy.size() > 0){

            initStrategy.addAll(extendedInitStrategy);

        }

        SpecimenOrObservationBase<?> sob = service.load(occurrenceUuid, null);

        if(sob instanceof DerivedUnit){

            try {

                return service.getDerivedUnitFacade(((DerivedUnit)sob), initStrategy);

            } catch (DerivedUnitFacadeNotSupportedException e) {

                logger.error(e); //TODO ...

            }

        } else {

            HttpStatusMessage.UUID_REFERENCES_WRONG_TYPE.send(response);

        }

        return null;

    }

Die Frage ist hier, ob der instanceof check wirklich notwendig ist oder abgeschwächt werden könnte. Im hiesigen Fall gibt es ja sowohl MediaSpecimen, die da nicht abgedeckt sind, als auch FieldUnits, die abgefragt werden und die inzwischen ja auch von der DerivedUnitFacade abgedeckt werden (genau, wir sollten die dann wohl mal umbenennen J ).

Letzteres sollte nach dem neuen Import zwar kein Problem mehr sein, in Zukunft sollten wir das aber besser händeln, da eigentlich nichts dagegen spricht auch FieldUnits als IndividualsAssociations zu speichern.

Die Methode wird an mehreren Stellen aufgerufen an denen man dann tlws. Checks einbauen muss, ob die Verwendung Sinn macht (können wir mal mündlich besprechen).

Meine Frage jetzt erstmal, ob dieser Check grundsätzlich überhaupt sein muss aus eurer Sicht. Vielleicht übersehe ich ja was.

Viele Grüße,

Andras M.

Actions #2

Updated by Andreas Kohlbecker over 6 years ago

Hallo,

ich verstehe das nicht ganz. Es ist doch genau anders herum: FieldUnit wird hier nicht abgedeckt, aber MediaSpecimen als Subklasse von DerivedUnit schon.

Wenn es darum geht, eine DerivedUnitFacade zu erstellen, dann sollte als übergebene occurrence FieldUnit sowohl als DerivedUnit möglich sein, was es in diesem Fall nicht ist. Der Check wäre somit unnötig, weil es ja eh schon eine SpecimenOrObservation ist.

Oder habe ich was übersehen?

Gruß,
Patrick

Actions #3

Updated by Andreas Kohlbecker over 6 years ago

Hallo,

dem was Patrick geschrieben hat schließe ich mich weitgehend an, aber wenn an die Konstruktoren der DerivedUnitFacade betrachtet wird klar dass eine Weiche benötigt wird die nach DerivedUnit und FieldUnit unterscheidet:

  • public static DerivedUnitFacade NewInstance(SpecimenOrObservationType type)
  • public static DerivedUnitFacade NewInstance(SpecimenOrObservationType type, FieldUnit fieldUnit)
  • public static DerivedUnitFacade NewInstance(SpecimenOrObservationType type, FieldUnit fieldUnit, DerivedUnitFacadeConfigurator config)
  • public static DerivedUnitFacade NewInstance(DerivedUnit derivedUnit)
  • public static DerivedUnitFacade NewInstance(DerivedUnit derivedUnit, DerivedUnitFacadeConfigurator config)
  • private DerivedUnitFacade(SpecimenOrObservationType type, FieldUnit fieldUnit, DerivedUnitFacadeConfigurator config)

es gibt keinen Konstruktor der eine SpecimenOrObservation instanz akzeptiert!

Andreas

Actions

Also available in: Atom PDF