If you have a computed field such as full_name, it would be very useful to be able to filter by this value. E.g.
{
users(where: { full_name: { _eq: "John Smith"}) {
...UserDetails
}
}
Yes exactly the same usecase for me. I output a datatable module and I want the user to be able to filter and sort by any value inside the datatable. Right now I have to disable those features for any computed field, which is really unintuitive.
+1
now receiving "field "computed" not found in type: 'table_order_by'" when trying to sort by computed field.
any chance to get this feature?
Interestingly on surface there are no visible limitations because this is working
SELECT public.calculate_something(entity) AS something FROM entity
WHERE public.calculate_something(entity) = 'something'
Just to add in on this, it could be useful to use a computed field as primary key
Example: I generate a slug for my projects and I want to get them with a query like:
query {
projects_by_pk(slug: "example") {
id
name
}
}
Or
query {
projects(where: {slug: { _eq: "example"}}) {
id
name
}
}
Also related, it would be neat if we could select computed columns for permission checks.
@marionschleifer @coco98 any chance of getting this into 1.3?
+1
Just to add in on this, it could be useful to use a computed field as primary key
Example: I generate aslugfor myprojectsand I want to get them with a query like:query { projects_by_pk(slug: "example") { id name } }Or
query { projects(where: {slug: { _eq: "example"}}) { id name } }
@Kosai106 Does this actually work?
@MarcelloTheArcane No, it's a request.
It looks fairly simple to implement, even though I might be mistaken.
Currently, my workaround is to create a SQL View, with all my table's field, and the computed field itself.
That's ugly, and prevents you from updating the whole view (you need to switch between two GraphQL root fields), but hey at least it works in queries.
If you need it to work in mutations, you need to create a new view with your computed field, add a relationship between your root table and the view, and filter from there. It requires a JOIN, which could hurt performance on an often queried table, and will be ugly, but it will work.
Since we're already at v1.3.0-beta4, I wouldn't expect the Hasura's team to ship this feature in v1.3.0. However, if they could, it would be awesome 馃挴
This would be a great feature!!
This is a must-have for my team
+1 is much needed to have this!
+1 - very important for our team.
+1
Adding my voice to this. Would really love to see this added!
This issue is the 4th most upvoted feature. Do you have any update on when this will be available? Please help us.
+1
+1
+1
+1
+1
+1
+1
I just want to chime in here to say that leaving +1 comments do not help. If you want to show support, give a 馃憤 to the initial post instead.
Most helpful comment
Also related, it would be neat if we could select computed columns for permission checks.