Open aragilar opened 1 week ago
On Sun, Jun 30, 2024 at 09:00:07PM -0700, James Tocknell wrote:
I'll try to produce a fix, but it would be good for a maintainer to check that
access_format
is the expected attribute, rather thanformat
which seems to exist on https://pyvo.readthedocs.io/en/latest/api/pyvo.dal.SSARecord.html#pyvo.dal.SSARecord.
I'd say this is a variant of #543; it actually is an extension of what it says in (1): iter_datalinks doesn't even work for all typed records, because for SSARecord doesn't.
And I'd fix it like #543; as it says in item (b) of the problem statement there, I think we should guess the columns for access_format and access_url by utype or UCD or something. Actually: let's drop this onto the DAL list: "In a generic datalink client, I want to find out whether there is a data product at all in some row, and when there is, whether it is a datalink document, i.e., it's media type. How do I do this in maximal generality?".
This problem is about as old as the VO itself, and has been discussed several times in several venues, but it pays to occasionally revisit it. Perhaps we can at least agree on a few ad-hoc conventions this time around.
It looks like
SSARecord
is missingaccess_format
, so when the adhoc service discovery of datalink fails (I need to look through that discovery logic as to why that's not succeeding),next(result.iter_datalinks())
hits the second case of checkingrow.access_format == DATALINK_MIME_TYPE
, which causes the error noted in the title.I'll try to produce a fix, but it would be good for a maintainer to check that
access_format
is the expected attribute, rather thanformat
which seems to exist on https://pyvo.readthedocs.io/en/latest/api/pyvo.dal.SSARecord.html#pyvo.dal.SSARecord.