Use astroquery.utils.tap rather than making our own URL calls #32
Comments
Cadair
changed the title
|
I just had a quick look into this, and the following code errors, and I'm not sure what the solution is. Thought I'd leave this here as a paper trail though. from astroquery.utils.tap.core import TapPlus
soar = TapPlus('http://soar.esac.esa.int/soar-sl-tap/tap')
tables = soar.load_tables(only_names=True)
for table in (tables):
print(table.get_qualified_name())
table = soar.load_table('time_series.time_series.v_solo_ll02_swapasmom_2')
print(table)with Retrieving table 'time_series.time_series.v_solo_ll02_swapasmom_2'
500 Error 500:
esavo.tap.TAPException: esavo.tap.TAPException: Schema cannot be null
Traceback (most recent call last):
File "/Users/dstansby/github/sunpy-soar/test.py", line 8, in <module>
table = soar.load_table('time_series.time_series.v_solo_ll02_swapasmom_2')
File "/Users/dstansby/mambaforge/envs/sunpy/lib/python3.10/site-packages/astroquery/utils/tap/core.py", line 177, in load_table
self.__connHandler.check_launch_response_status(response,
File "/Users/dstansby/mambaforge/envs/sunpy/lib/python3.10/site-packages/astroquery/utils/tap/conn/tapconn.py", line 683, in check_launch_response_status
raise requests.exceptions.HTTPError(errMsg)
requests.exceptions.HTTPError: Error 500:
esavo.tap.TAPException: esavo.tap.TAPException: Schema cannot be null |
|
I asked Helen and she said to drop the part before the first |
|
|
Hey there :) herroyalmaj |
|
I have had some success: |
|
OK, so I think this has some advantages, mainly that constructing a SQL like query is nicer than url parameters and that it automatically makes us an astropy table (which we can clean up a little using the built in query response table stuff). I think that if I was going to fall all the way down this pit, I would rewrite the attr walker to return some kind of structured thing representing the parts of the Also, I think this could end up being one of the few clients where we can pass the ORs up to the web service which would be a fun exercise in breaking Fido. |
|
I also found this: https://pypika.readthedocs.io/en/latest/ which might be useful to stop us having to write a lot of SQL by string formatting, it might be a bit overkill though. |
|
Maybe irrelevant now that use of tap_end_point = 'http://soar.esac.esa.int/soar-sl-tap/tap/'
payload = {
'REQUEST': 'doQuery',
'LANG': 'ADQL',
'FORMAT': 'json',
'QUERY': adql_query
}
r = requests.get(f'{tap_end_point}/sync', params=payload)This is more clear and maintainable, the ADQL query is automatically URL-escaped, and you can still get the actual full URL with |
|
I just learned from @herroyalmaj that TapPlus now recommends to use PyVO instead. I would say that it doesn't change much to PR #129, as most of line changes in that PR were to make the ADQL queries non-URL-escaped. The transition to PyVO should then not be too difficult as a next step. |
|
In that case we should update the current PR to use that. |
Provide a general description of the issue or problem.
https://astroquery.readthedocs.io/en/latest/utils/tap.html
The text was updated successfully, but these errors were encountered: