I'm submitting a ...
PostGraphile version: v4.3.3
Expected behavior:
Currently, using custom composite types and separate tables are the only way to expose nested objects in your generated GraphQL schema. It would be nice if there were an easy way to map columns named with the same prefix to nested properties on a single object. For example, assuming I have several columns with the prefix products.inventory_*, I'd like to be able to map those under a single object Product.inventory.* in the GQL schema.
This could be implemented on top of the existing @name smart comment, extending the current implementation to support nested paths i.e.
comment on column products.inventory_method is
E'@name inventory.method';
However, in addition to explicit mappings, a more dynamic option (where the user can specify a path prefix) is probably desirable to avoid unnecessary verbosity:
-- @nested <prefix> <name?>
-- default `name` in this case would be `inventory`
comment on table products is
E'@nested inventory_*';
comment on table products is
E'@nested inventory_* inventory';
If we implement this, I think it should also allow arbitrary groupings. In addition to the glob pattern, we could also allow something like:
@nested street_address,city,country,postcode address
This would combine with the standard @name smart comment in case you want to, e.g., rename postcode to zipcode.
We could potentially implement this in a backwards compatible way by deprecating the existing fields and adding the nested object too. This could be an option.
For querying, you can already do this using a computed column:
CREATE TYPE nested_inventory AS
(
warehouse text,
location text
);
CREATE FUNCTION products_inventory(products products) RETURNS nested_inventory AS
$$
SELECT products.warehouse::text, products.location::text
$$ LANGUAGE sql STABLE;
That doesn't solve it for mutations though, but perhaps this is already sufficient for your use case.
Most helpful comment
If we implement this, I think it should also allow arbitrary groupings. In addition to the glob pattern, we could also allow something like:
This would combine with the standard
@namesmart comment in case you want to, e.g., renamepostcodetozipcode.We could potentially implement this in a backwards compatible way by deprecating the existing fields and adding the nested object too. This could be an option.