Closed sebastian closed 3 years ago
Please make a proposal and discuss before implementing.
How about adorning queries with:
comment: string
tags: string[] // in UI as a space or comma-separated string
And the respective UI for them? Then you can view queries of a certain tag and see their comments as well.
Yes, I was thinking something similar, BUT the UI is going to be the tricky part! How do you make a UX that allows someone to easily find back to old queries in a useful way?
Adding tags might be overkill for now. We could add a query search page that can look for keywords in the query statement plus filter by date and/or data source. The comment field might be useful if we want to allow query editing after the fact (otherwise, comments could be included in the query statement).
(otherwise, comments could be included in the query statement).
The primary use case we are trying to solve for here is one where the user doesn't know ahead of time which queries are going to end up useful. I.e. they spray and pray, and later want to be able to mark those that were useful. Because of this adding comments as part of the SQL is not going to be a good approach.
I think doing either a comment or tags would be enough. Maybe comments is more flexible. Someone can still choose to add #whatever
in their comment and then use that to filter later.
Postgres has some nice text search features AFAIK. We could use that to filter on the comment/tags field.
Ok, discussed further:
.
or an x
to simulate just marking a query. They can add #my-best-query
to tag. They can add freeform text to add more contextNote: I envision the query page to be across all queries for a user across all data sources! I.e. it could be a button next to the data sources button in the top left:
Some questions:
Do we show in-progress queries in this page? This may complicate implementation.
I would say yes, but in no different way than we do for queries that are completed. Basically just a complete list of the queries that originate from a user irrespective of their state.
Do we show results if the query was successful? This may cause bloat.
I'd say no. You get the answer by following the link to the query page.
Can we filter by date? This allows to jump to the past without clicking "Load more" so often.
It would be nice. Like the time filter we use quite often in the admin section.
Can we filter by data source like in admin's auditlog/queries? I think this is better than including the data source in the search term.
Yes, you are right. It would be better. If we have a filter side-bar anyway, maybe we can add filtering by data source there.
Can we delete queries from this page? Can we set notes on queries from this page?
Delete queries: no. See notes: yes.
Should we go with a live view or a react page with API? Both have their pros and cons, and also depends on the answer of the previous question.
I would personally prefer a live view, but I'm happy to let you take a lead on this as you go about implementing it.
Thanks for the detailed response!
See notes: yes.
What about setting notes, i.e. will the query be entirely immutable? I'm asking because the mutation side is in react and makes the decision more difficult.
Let's make the notes immutable on the query list page. If you want to edit or delete the note you can click into the query view. I think we are offering enough functionality this way, and reduce the complexity of the implementation significantly this way too.
If you want to edit or delete the note you can click into the query view.
Unfortunately, the permalink is immutable too, and we don't provide a way to navigate to a specific query from the data sources page. This means that mutating (set note or delete) an old query would be very difficult because you have to find it by scrolling in the data source.
Oh, I see! Thank you for clarifying! In that case I think we might have to find a way to edit the notes after all. Which do you think is easier? Allow note editing on permalinked queries in the case of the viewer being the query runner, or allowing for inline note editing in the overview?
I think allowing users to set note from the permalink is easier since it's in react already. Making the history view immutable will save us some complexity, which seems to be high enough already...
Report from Vassili:
Vassili wishes for some way of being able to find back to relevant queries, and some way of adding context so he knows what they are about.