Closed sarahzinger closed 3 years ago
:+1: let's do the hardcoded list of regions first and create a follow-up issue to dynamically obtain those.
One more thing here to do in sqlds
is that, at the moment, only one db
instance is supported per data source. Since we are changing the region in the query, the package should support to have a db
per query (probably falling back to a default db
).
Yes! I think this is kind of covered by this issue. Each query row in the editor should be able to override region and db.
Regions can be loaded for the describe endpoint API. For reference, see how we do this in the CloudWatch data source backend.
BTW, I just learned that regions are different per service. This means we cannot use EC2 regions and as far as I can see, there is no endpoint/method to dynamically retrieve those for athena. I just copied the ones documented: https://docs.aws.amazon.com/general/latest/gr/athena.html
Closed with #30
The region will be used when creating an Athena API client, so we'll need this for any API call in the plugin. Like in the CloudWatch data source, the list of regions should include a value named
default
. If this is selected, the region that was specified in the config page should be used.Regions can be loaded for the describe endpoint API. For reference, see how we do this in the CloudWatch data source backend. To load regions in the Athena frontend, you must perform a GetResource request to the backend. Currently, sqlds has no endpoint for regions. Technically, it could be a part of the completeable interface, but that doesn't feel right because regions is not a generic database component. I think sqlds should expose a call resource endpoint that the driver (our Athena backend in this case) can use to implement any rest routes. This call resource handler could be mounted under the path 'driver' or something to make sure that the paths don't collide with the ones for completeable.
If you want to get started quickly, you can use a hard coded regions that are defined here.