Create computed field that returns single row

[dariocravero]

Hi, How're you?

Have you considered allowing relations through computed fields?

I'd like to skip making a view if possible to avoid the extra maintenance step. I know that an alternative is to use a computed field to return a setof <table-name> but if I only need an object relation, how can I approach that?

Thanks! Darío

[tirumaraiselvan]

I think we should extend support for computed fields which return <table-name> instead of only set of <table-name>. We did this for top-level functions already: https://github.com/hasura/graphql-engine/issues/4299

[dariocravero]

That'll be amazing @tirumaraiselvan!! Thanks. Let me know if I can be of any help.

[dariocravero]

Have you also considered allowing filtering by computed fields in where? I think I saw this in another issue but couldn't find it.

[esseswann]

@dariocravero It's tracked here https://github.com/hasura/graphql-engine/issues/3772

[dariocravero]

Is this being considered as parts of the ongoing computed fields improvements?

[dariocravero]

Also, somewhat related but since remote joins now support computed fields as part of their relations, would it be possible to use computed fields as part of relations too? Eg, a computed field returns an id, then we can use that in a relation to another table

[jgoux]

This feature would be very helpful for us as well!

We enforce our authorization rule per node, for example, we have a "Project" entity that checks if the user is a member of the project, once the user is allowed to enter the node, they can access the project's fields.

In order to keep practical queries like all the by_pk ones, we add them when needed in those nodes as computed fields :

projects_by_pk("1") {
  task_by_pk("123") { name }
}

Here task_by_pk is in fact a computed field on the "projects" table. It works beautifully, but the fact that we get an array back is a real pain on the frontend as we have to unwrap the single entity returned by the function every time.

I hope it will be considered, as the feature already exists for top-level functions I guess most of the solution is already there. 😄

[akhilrajvc]

Hi, Is there any update on this

[andim27]

"+"

[mcsimps2]

Eager for this feature as well. The resulting code without this functionality is very spaghetti. Lots of developer confusion seeing myComputedField[0].foo in the codebase instead of simply just myComputedField.foo.

[debagger]

I found some workaround for my case. This can be achieved by creating a view. Make view with desired fields and id of parent table, than make object reference from parent table to the view. But it little bit wired solution...