Hey @codingkarthik, is there a commit where this issue was solved?

This would really help to clean up my application's API.

I ran into an unusual case where using the standard Hasura relationships is not possible – I'm tracking several views which derive data from a very expensive to generate view (a recursive query which runs against a >100GB table). I've been able to set up relationships between existing tables and these views with great API performance, but as soon as I want to query a property inside an object returned by, e.g. an array relationship of the expensive view, the SQL produced by Hasura would require scanning the full, expensive view (no matter how high I set the COSTs).

I'm able to work around this issue nearly-perfectly with computed fields, though. Instead of adding a relationship from a field of the expensive view to another table, I simply added a computed field which does the lookup manually:

CREATE FUNCTION authchain_migration_transaction(authchain_migration_row authchain_migrations_view) RETURNS transaction
  LANGUAGE sql IMMUTABLE
AS $$
  SELECT * FROM transaction WHERE internal_id = $1.migration_transaction_internal_id LIMIT 1;
$$;
COMMENT ON FUNCTION authchain_migration_transaction (authchain_migrations_view) IS 'This function powers the "transaction.authchains[n].migrations[n].transaction" computed field in migration objects. This is a workaround to improve performance over an equivalent "transaction" standard Hasura relationship. When implemented as a relationship, the Hasura-compiled SQL query requires a full scan of the authchain_migrations_view, which is extremely large and expensive to compute.';

This works almost perfectly, however the result returned by Hasura is an array (of length 1) rather than an object:

query GetAuthheads {
  transaction(
    where: {
      internal_id: {
        _eq: "167243311"
      }
    }
  ) {
    internal_id
    authchains {
      migrations {
        migration_index
        transaction {
          internal_id
        }
      }
    }
  }
}

Returns (note the [] around each transaction object):

{
  "data": {
    "transaction": [
      {
        "internal_id": 167243311,
        "authchains": [
          {
            "migrations": [
              {
                "migration_index": 0,
                "transaction": [{ "internal_id": 167243311 }]
              },
              {
                "migration_index": 1,
                "transaction": [{ "internal_id": 172962140 }]
              }
            ]
          }
        ]
      }
    ]
  }
}

When it should return (without the array):

{
  "data": {
    "transaction": [
      {
        "internal_id": 167243311,
        "authchains": [
          {
            "migrations": [
              {
                "migration_index": 0,
                "transaction": { "internal_id": 167243311 }
              },
              {
                "migration_index": 1,
                "transaction": { "internal_id": 172962140 }
              }
            ]
          }
        ]
      }
    ]
  }
}

Is there some why to configure this computed field to return an object rather than an array here? (Related: #4678)

track functions that return a single row #4299

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions