Is it possible to give an alias to a query parameter?

Support
1

Query parameters are great for obvious reasons. When you make Data Explorer queries available to less-than-technical users though, they can sometimes be confused by the name (even if it’s just a variable name with an underscore).

Can you give an alias to a query parameter so it shows up with a nicer name below the query?

2

Hi @jordan-violet :wave: I think perhaps one can do something like this - Is this what you mean?

SELECT column_name AS alias_name
FROM table_name;
...

or like

SELECT column_name(s)
FROM table_name AS alias_name
....
3

No sorry, the input parameters to the query. Like so:

image
image1463×500 18.1 KB

1 Like
4

ooh sorry I misunderstood your question! hmmm :thinking:

6

I believe you can edit the query in Data Explorer and add a description about how the param should be set. It will show up when the report is run:

IMG_0281
IMG_02811431×739 83.1 KB

IMG_0282
IMG_0282947×579 54.7 KB

1 Like
7

Yep, I have that now, but it’s just not as polished when you’re trying to make these reports friendly to very non-technical people in places like sales, marketing, etc.

In fact, it’d be nice if it went one step further and also gave you the option of defining a tooltip/info icon description as well.

1 Like
8

DE is very raw… building a different UI (be it a webpage or a spreadsheet or an application) is probably a good idea.

A great example is Grafana!

Grafana has a live demo of reports about their community pulled from Data Explorer in real time.

4 Likes
9

Yeah, we run Tableau in our business and we do export all Discourse data so it can be used there.

But I do enjoy bringing users, including internally, into the platform. I always attempt to champion for less tools as much as possible and avoid too much sprawl.

4 Likes
10

FWIW, I really like this idea. I think having a ‘friendly label/placeholder’ would be a good addition. I am not sure how to achieve it though. :thinking:

2 Likes
11

So many options!

One of the more simple solutions would be to check for an optional label variable in the current format you all use, e.g.:

-- [params]
-- text :user_group
-- label: "The Salesforce account name for the customer you want to look up in this query."
-- text :topic_id

Admittedly I haven’t been a full-time dev in over 5 years and going now, so I can’t pretend to know the specifics of the current implementation nor the possible complexities of this next suggestion…but it’d be awesome if you implemented Front Matter at the start of the SQL query. Front Matter can be yaml, toml, or even json and certainly looks prettier than the current implementation. It visually looks as though it’d be easier to add options too, in my opinion. A query with a theoretical Front Matter implementation might look something like this:

---
user_id:
  description: "The Salesforce account name for the customer you want to look up in this query."
  tooltip: "Get this from users Salesforce account, usually associated with their email domain. It should be an exact match."
topic_id:
  description: "This is the ID of the topic you want to look into."
event_attendance_type:
  default: 0
---

SELECT ue.user_id, u.name, u.title, ue.email
FROM discourse_post_event_invitees ei
JOIN posts p ON p.id = ei.post_id 
JOIN user_emails as ue ON ei.user_id = ue.user_id
JOIN users as u on ei.user_id = u.id
WHERE p.topic_id = :topic_id
AND ei.status = 0
3 Likes