Implement python 'or' operator for fallback keys

[reweeden]

It is starting to come up more often that we need to try getting data from one key, and fall back to a different key if the first doesn't exist. Currently this needs to be implemented by setting up two items in the template and then resolving the fallback during the UMM-G generation step, using these changes, it could be implemented directly in the metaspec file.

Pull Request Checklist

I have:

• performed a self review of my code I&A code style
  • Resources and Data Structures are sorted by ABC or a defined sorting pattern
• updated the documentation accordingly
• verified required action checks are passing
• bumped the version number as appropriate

[gjclark]

Great changes! This means that we should be able to modify our metaspecs that allow both keys to be optional whenever we have time to.

[reweeden]

Which ones are you referring to? Just because of how the whole template processing works in mandible, both the left and right sides of the 'or' operator will be processed when the template is evaluated. So if you have a mapped on either side of the 'or', both of those will have to complete without error even if the right hand side is ultimately ignored, meaning it can't be used to skip the source query step for a key if a different one exists. Not sure if that was what you were thinking of.

[gjclark]

Which ones are you referring to? Just because of how the whole template processing works in mandible, both the left and right sides of the 'or' operator will be processed when the template is evaluated. So if you have a mapped on either side of the 'or', both of those will have to complete without error even if the right hand side is ultimately ignored, meaning it can't be used to skip the source query step for a key if a different one exists. Not sure if that was what you were thinking of.

I was thinking here:

class UavsarUmmgBase(AsfUmmgBase):
        ]

    def get_beginning_date_time(self) -> datetime.datetime:
        return self.get_datetime(
            self.product_metadata["productStartDateTime"],
            self.product_metadata["productDateTimeofAcquisition"],
        # TODO(reweeden): Replace with a single key once mandible supports
        # fallback mappings
        return to_umm_datetime(
            self.product_metadata["beginningDateTime"] or self.product_metadata["dateOfAcquisition"],
        )

I was actually going to suggest even linking this PR in that comment so that it's clear when "mandible supports fallback mappings."

[reweeden]

OK, yep! Although I don't think I'm going to actually make that change on the PR right now because I don't want to deal with having to make a new mandible release and update the dependencies. Because if we update mandible, we'd probably want to update it for all workflows so everything is on the same version, but that would mean applying that same change to the consolidated repo, so I'd rather just wait until we're done migrating stuff there and then do the update only once in the consolidated repo.

[gjclark]

OK, yep! Although I don't think I'm going to actually make that change on the PR right now because I don't want to deal with having to make a new mandible release and update the dependencies. Because if we update mandible, we'd probably want to update it for all workflows so everything is on the same version, but that would mean applying that same change to the consolidated repo, so I'd rather just wait until we're done migrating stuff there and then do the update only once in the consolidated repo.

Absolutely