Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-32414

Exposure ID Gen 3 disassembled component broken

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: afw, obs_base
    • Labels:
      None
    • Story Points:
      4
    • Epic Link:
    • Sprint:
      AP F21-6 (November)
    • Team:
      Alert Production
    • Urgent?:
      No

      Description

      DM-29955 added an id component to Exposure composite disassembly but neglected to test it. Add the correct test and fix any failures.

        Attachments

          Issue Links

          relates to

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DM-29955 Add ExposureInfo id getter (replacement for VisitInfo.getExposureId())

          • Done

            Activity

            Ascending order - Click to sort in descending order
            Hide
            Permalink
            tjenness Tim Jenness added a comment -

            A quick summary of the current situation.

            • With read component "id" the "metadata" is the declared responsible component.
            • The FileFormatter reads the metadata and attempts to call getComponent on it using the storage class delegate.
            • The generic PropertyList StorageClass doesn't have a delegate and so this raises TypeError.
            • There is no useful delegate we could register for PropertyList that would understand what "id" component meant because we have no way to tell such a delegate which header should be used for that component.

            What I think this means is that we need some alternate path to handling these cases such that if there is no delegate we use the composite delegate and ask it to get the value from the responsible component. This will likely need new API for StorageDelegate.

            Show
            tjenness Tim Jenness added a comment - A quick summary of the current situation. With read component "id" the "metadata" is the declared responsible component. The FileFormatter reads the metadata and attempts to call getComponent on it using the storage class delegate. The generic PropertyList StorageClass doesn't have a delegate and so this raises TypeError. There is no useful delegate we could register for PropertyList that would understand what "id" component meant because we have no way to tell such a delegate which header should be used for that component. What I think this means is that we need some alternate path to handling these cases such that if there is no delegate we use the composite delegate and ask it to get the value from the responsible component. This will likely need new API for StorageDelegate.
            Hide
            Permalink
            krzys Krzysztof Findeisen added a comment -

            Hi John Parejko, can you review this quick patch on DM-29955? It's 12 lines total, including afw#616.

            Show
            krzys Krzysztof Findeisen added a comment - Hi John Parejko , can you review this quick patch on DM-29955 ? It's 12 lines total, including afw#616 .
            Hide
            Permalink
            Parejkoj John Parejko added a comment -

            Thanks, this all looks good (and I'm glad you updated that comment in the assembler).

            Show
            Parejkoj John Parejko added a comment - Thanks, this all looks good (and I'm glad you updated that comment in the assembler).

              People

              Assignee:
              krzys Krzysztof Findeisen
              Reporter:
              krzys Krzysztof Findeisen
              Reviewers:
              John Parejko
              Watchers:
              John Parejko, Krzysztof Findeisen, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.