Derived types include selector for the derived types when using relational polymorphism

[FelixZY]

Derived types include selector for the derived types when using relational polymorphism

[benjie]

Contrary to what I said yesterday, point 1 isn't actually a bug. Refs shouldn't inherit behaviors from the relations, they're explicit - e.g. you might @behavior -* a organization_members join table, but use a ref to allow going straight from organization to members.

So actually the bug was just point 2, which is fixed in #2149

[benjie]

Reproduction code:

DROP SCHEMA if EXISTS "dansdata" cascade;
CREATE SCHEMA "dansdata";
set search_path to dansdata;

--------------------------------------------------------------------------------

CREATE TYPE dansdata.profile_type AS ENUM('individual', 'organization');
comment on type dansdata.profile_type is '@name TypeOfProfile';

CREATE TABLE dansdata.profiles (
  id UUID DEFAULT gen_random_uuid () PRIMARY KEY,
  type dansdata.profile_type NOT NULL,
  name TEXT NOT NULL
);

comment ON TABLE dansdata.profiles IS
E'@interface mode:relational type:type\n'
'@type individual references:individuals\n'
'@type organization references:organizations\n'
'@name Profile\n'
'\n'
'Represents an entity with profile data.';

CREATE TABLE dansdata.individuals (
  id UUID PRIMARY KEY REFERENCES dansdata.profiles (id) ON DELETE cascade
);

comment ON TABLE dansdata.individuals IS E'@name Individual\nRepresents an individual person.';

CREATE TABLE dansdata.organizations (
  id UUID PRIMARY KEY REFERENCES dansdata.profiles (id) ON DELETE cascade
);

comment ON TABLE dansdata.organizations IS E'@name Organization\n\nRepresents an organization.';

--------------------------------------------------------------------------------

CREATE
OR REPLACE function dansdata.create_individual (name TEXT) returns dansdata.individuals AS $$
  WITH "profile" AS (
    INSERT INTO dansdata.profiles("type", "name") VALUES ('individual', name) RETURNING *
  ) INSERT INTO dansdata.individuals("id") (SELECT id from "profile") RETURNING *;
$$ language sql volatile strict security invoker;


CREATE
OR REPLACE function dansdata.create_organization (name TEXT) returns dansdata.organizations AS $$
  WITH "profile" AS (
    INSERT INTO dansdata.profiles("type", "name") VALUES ('organization', name) RETURNING *
  ) INSERT INTO dansdata.organizations("id") (SELECT id from "profile") RETURNING *;
$$ language sql volatile strict security invoker;

[benjie]

The bug is related to this code:

crystal/graphile-build/graphile-build-pg/src/plugins/PgPolymorphismPlugin.ts

Lines 591 to 598 in f762ee3

	// TODO: normally we wouldn't call `getBehavior` anywhere
	// except in an entityBehavior definition... Should this be
	// solved a different way?
	const behavior = getBehavior([
	relationSpec.remoteResource.codec.extensions,
	relationSpec.remoteResource.extensions,
	relationSpec.extensions,
	]);

Specifically the behaviors coming out of that are '' (which is not unexpected given how behaviors work); however, we are expecting the -single behavior to come out of it; the one that is added here:

crystal/graphile-build/graphile-build-pg/src/plugins/PgPolymorphismPlugin.ts

Line 702 in f762ee3

return [behavior, "-connection -list -single"];

We know it's added because the relationship is not added to the interface type; and yet it is still added (via refs, incorrectly) to the child types.

Really there's two bugs here:

1. The ref behaviors aren't correctly being influenced by the parts that make up the ref (see the TODO linked above - yes we're doing this the wrong way)
2. These specific refs, independent of behaviours, shouldn't be added in the first place.

Solving either one of these bugs will fix the issue, but both should be solved.