ISIS Serial Number translation only uses the last translation
In the ISIS serial number translation logic, the SQLAlchemy model converts the PVL translation string into a NextedJsonObject which removes duplicate keys such as the multiple translations. Then, the JSON object gets turned back into a PvlModule. This results in strange behavior like the Galileo translation going from:
Group = Keyword1
Auto
InputKey = SpacecraftName
InputGroup = "IsisCube,Instrument"
InputPosition = (IsisCube, Instrument)
OutputName = Keyword1
OutputPosition = (Group, SerialNumberKeywords)
Translation = (Galileo, GalileoOrbiter)
Translation = (Galileo, GALILEOORBITER)
Translation = (Galileo, "Galileo Orbiter")
Translation = (*, *)
End_Group
to
Group = Keyword1
Auto
InputKey = SpacecraftName
InputGroup = "IsisCube,Instrument"
InputPosition = (IsisCube, Instrument)
OutputName = Keyword1
OutputPosition = (Group, SerialNumberKeywords)
Translation = (*, *)
End_Group
This in turn results in invalid serial numbers because the value on the label is "Galileo Orbiter" and instead of getting "Galileo" as the first keyword, you get "Galileo Orbiter".
I think the trick here is to store the translation PVL as a string type in the DB and then to lean more heavily on the PVL library to encode/decode on read/write. That will maintain the duplicate keys.
As a more meta question - what options exist to avoid using duplicate keys in the translation tables? Duplicate keys are quite problematic for JSON (most, but not all implementations as duplicate keys are not explicitly prohibited), YAML, python dicts, and likely more). If we needed to encode this as JSON, we could use an array:
Translation = [(Galileo, GalileoOrbiter), (Galileo, GALILEOORBITER), (Galileo, "Galileo Orbiter"), (*, *)]
I would guess that, on the ISIS side, the translation entries are just being iterated over anyway until one works?
Yes, they are processed from top to bottom, so order could be important, but I don't know of any cases like that. The first one that works is the winner.