Replies: 5 comments 5 replies
-
Great idea, would make life a lot easier |
Beta Was this translation helpful? Give feedback.
-
An additional and very important advantage of this approach is that, as it seems to me, there are usually indexes on IDs, and filtering by string will usually occur without an index |
Beta Was this translation helpful? Give feedback.
-
sound great, will you implement this feature soon ? @polmonso |
Beta Was this translation helpful? Give feedback.
-
@linhmiyano99 I don't think I'll have time at the moment... Anybody can take it. |
Beta Was this translation helpful? Give feedback.
-
Well we've already implemented what looks like this feature almost exactly. I think we could contribute it to the upstream. |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
In many DBs there's an ID / Name pattern. So the id is integer and name is String for human readable representation.
When using Native Filters you have to decide to use id field or String field,
but ideally you'd like to use the id field for the technical filter and
use the name for labelling only.
example table:
Benefits would be:
Describe the solution you'd like
It would be great to have an option 'verbose column' (or similar) in the native filter's parameters. That column selection is optional, but would take care about the ID -> string mapping.
In the UI filter box a user would just see values like 'sports', 'cars', 'entertainment', but it could be controlled by preselect_filter using IDs 1, 2, 3.
Describe alternatives you've considered
If the 'verbose' field could be entered using a dedicated SQL expression
potentially controlled/secured by some JINJA templating, that would
maby more technical, but also more flexible.
This discussion is a copy of #19184 but updated to Native Filters. I didn't update the images, if it helps spring the discussion I'd do some mock ups.
Beta Was this translation helpful? Give feedback.
All reactions