falcon
falcon copied to clipboard
plotly
backend: provide grid names
cc/ @tarzzz @mfix22 @briandennis
Re/ this comment in #472.
At the moment, a request to Falcon's GET /queries returns an array of query objects {requestor, fid, uids, refreshInterval, query, connectionId} that doesn't include grid name.
The proposal here is that we ensure the returned query objects include the property filename. With this approach, #472 wouldn't need additional code to request the grid names.
@tarzzz I imagine that for a given fid, the grid name (filename?) can change (i.e. users are allowed to rename the grid without changing its fid). Is that so?
If this is the case, there is no point in saving the grid name in Falcon's queries.yml. Instead, requests to GET /queries and GET /queries/:fid should trigger requests to getGridMeta.
Note to myself. This proposal requires that we change the logic in https://github.com/plotly/falcon-sql-client/blob/52a78ed13b196024dc2e985ebbd1b1780e84677a/backend/routes.js#L658-L703
This could get expensive if there are 100 queries, that's 100 calls to the API right?
I imagine that for a given fid, the grid name (filename?) can change (i.e. users are allowed to rename the grid without changing its fid). Is that so?
That's correct.
This could get expensive if there are 100 queries, that's 100 calls to the API right?
https://api.plot.ly/v2/grids#lookup doesn't support listing all files :(
@n-riesco You should be able to use: https://api.plot.ly/v2/folders#all (with the query-parameter as grid ) to get all the grids for that user.. (which can then be filtered for the fid from falcon .. !!
That will also be very expensive if there are many grids... some users have 10k grids
What we would need is to ask the API "what are the names of these N fids?"
That will also be very expensive if there are many grids... some users have 10k grids
True. Unfortunately, we don't have any endpoint at the moment which takes a list of fids and return only their metadata.. !! Either we can list them all, or we can get them iteratively using detail endpoint.. !!
Yep, and what I'm saying is that neither of these are going to be great from a performance POV.