Update HERD.get_key to replace ValueError with return values

[oruebel]

Motivation

HERD.get_key currently raises a number of different errors. I propose to change the errors to more useful return values:

• If no key is found return None instead of raising a ValueError
• If multiple matching keys are found, then return a list of Key objects rather than raising a ValueError

Alternatively, we could also always return a list of Key objects such that the list is empty when no Key is found, has 1 element when an exact match is found, and has multiple elements if many keys match.

Checklist

• Did you update CHANGELOG.md with your changes?
• Have you checked our Contributing document?
• Have you ensured the PR clearly describes the problem and the solution?
• Is your contribution compliant with our coding style? This can be checked running ruff from the source directory.
• Have you checked to ensure that there aren't other open Pull Requests for the same change?
• Have you included the relevant issue number using "Fix #XXX" notation where XXX is the issue number? By including "Fix #XXX" you allow GitHub to close issue #XXX when the PR is merged.

[oruebel]

@mavaylon1 what do you think. What is the most appropriate behavior for HERD.get_key?

[mavaylon1]

@mavaylon1 what do you think. What is the most appropriate behavior for HERD.get_key?

So this kind of comes to what I was thinking for "automatically resolving keys that exist". The user only calls this method when reusing a key for add_ref. If we actually make this resolution automatic in add_ref, then the get_key would most likely be a private method to aid that resolution (with modifications). At the end of it, the behavior of get_key is probably going to change, but your changes are also fine for the time being. Thoughts?

Another change we should do:
I think one idea is to check the existence of keys and entities before anything else in add_ref. This way we don't partially populate the HERD tables because that does happen if we catch the error down the road as we do now.

[oruebel]

I think one idea is to check the existence of keys and entities before anything else in add_ref. This way we don't partially populate the HERD tables because that does happen if we catch the error down the road as we do now.

Yes, we should do error checks first

then the get_key would most likely be a private method to aid that resolution (with modifications)

I think having a way for users to lookup keys will be useful (same for entities, objects, and files), not because they are needed for add_ref, but as a means for the user to query HERD.

[oruebel]

So this kind of comes to what I was thinking for "automatically resolving keys that exist". T

I think for keys we probably need a flag to indicate whether to reuse keys or create a new key.

[mavaylon1]

I don't think changing to None is more informative. I like the fact the error tells you why. As for the second one, I think that's fine. I will continue this PR.