Support ommitting fields with smart comments about pg-many-to-many HOT 13 CLOSED

@benjie I understand that the opt-in comments won't change, it would need a different plugin for that. (I'll try to write one as a replacement for many-to-many).
Still, @omit doesn't work properly on the constraints here, and I don't want to omit (automatically or not) whole tables.

from pg-many-to-many.

👍 I'm comfortable with those caveats. We can revisit if/when @include gets implemented.

from pg-many-to-many.

@omit manyToMany is supported in v1.0.0-beta.9.

from pg-many-to-many.

Thank you, it works great!

from pg-many-to-many.

Are you sure @omit isn't working?

With this schema..

create table p.foo (
  id serial primary key,
  name text not null
);

create table p.bar (
  id serial primary key,
  name text not null
);

create table p.baz (
  foo_id int constraint baz_foo_id_fkey references p.foo (id),
  bar_id int constraint baz_bar_id_fkey references p.bar (id),
  primary key (foo_id, bar_id)
);

comment on constraint baz_bar_id_fkey on p.baz is E'@omit';

...the Foo type has a barsByBazFooIdAndBarId field, but the Bar type does not have a a foosBy... field.

I do agree that support for @deprecated should be added.

from pg-many-to-many.

Quick side note.. PostGraphile currently only respects the @deprecated smart comment on table columns, not constraints. @benjie, in theory, should @deprecated on constraints be supported in PostGraphile core?

from pg-many-to-many.

Yes. Probably this plugin should be updated to support it:

https://github.com/graphile/graphile-engine/blob/master/packages/graphile-build-pg/src/plugins/PgColumnDeprecationPlugin.js

It turns out that we don't actually pass through the relevant constraint on scope, so that would need adding first:

https://github.com/graphile/graphile-engine/blob/b6fbfb849ee50e29b6c53114cb159dc4f12ddd19/packages/graphile-build-pg/src/plugins/PgBackwardRelationPlugin.js#L222

from pg-many-to-many.

@mattbretl @omit is not working for me, neither on the column nor on the constraint. The expected result would be

• Foo having a bazsByFooId field (1:N)
• Foo not having a barsByBazFooIdAndBarId field (N:N)
• Bar having a bazsByBarId field (1:N)
• Bar not having a foosByBazBarIdAndFooId field (N:N)
• Baz having a foo field (N:1)
• Baz having a bar field (N:1)

I'd rather see an opt-in smart comment on the junction table than some opt-out smart comment on individual foreign key constraints, as my schema has much more "accidental" many-to-many relations than it has intentional ones.

from pg-many-to-many.

Smart comment omits should still be opt-in currently; but you can write a plugin to automatically tag join tables as omitted. You can base it on this plugin:

https://www.graphile.org/postgraphile/plugin-gallery/#Customisation__OmitMutationsByDefaultPlugin

But maybe change it to omit tables that have a composite primary key?

from pg-many-to-many.

Foo not having a barsByBazFooIdAndBarId field (N:N)

I agree, it's omitting one direction but not the other. That needs to be fixed.

Bar having a bazsByBarId field (1:N)
Baz having a bar field (N:1)

I disagree with these two. If you've explicitly put an @omit comment the constraint between bar and baz, neither of those fields should be present. It's worth considering a way to allow that specific outcome, perhaps @omit manyToMany?

from pg-many-to-many.

I fixed the @omit issue which was causing barsByBazFooIdAndBarId to appear in the schema via #24. v1.0.0-beta.8 includes the fix.

I'll tackle @omit manyToMany next.

from pg-many-to-many.

Feedback welcome on #25.

@benjie, any reason to avoid extending @omit like this? The simple collections feature uses @simpleCollections omit, so I could see this being implemented as @manyToMany omit. I don't have a strong feeling either way.

from pg-many-to-many.

There's two main issues; first is that it prevents the use of aliases:

https://github.com/graphile/graphile-engine/blob/d723558b769777c4a9e572d502f1f54844207138/packages/graphile-build-pg/src/omit.js#L13-L35

I don't think that's a big deal though.

Second is that if we add an @include smart comment later which inverts @omit then we won't know about these custom omit tags. We can probably solve this by adding an API to add these custom omit tags into the known list, so just be aware that this is something you should remind me about if I ever implement @include. I'm not likely to do that in the next 6 months.

from pg-many-to-many.