Andreas Bergmaier

Looking forward to v5 :-) Didn't expect this to be changed easily, but imo it's something we need to take into account when redesigning `@omit read`. What shorter-term alternatives can...

OK I don't know how `@include` is supposed to work, I imagined it could be used together with `@omit`, overpowering each other (at least on different stages, like `@omit`ing a...

I had expected exactly this to happen: all the types get created and registered first, then afterwards their `fields` thunks are evaluated and can already fetch any type by name....

Ah, found it: the `performNonEmptyFieldsCheck` option causes the thunk to be evaluated prematurely (explicitly calling `Self.getFields()` to check its `.length`). Tbh I'm not quite sure why this doesn't fail more...

But the schema wouldn't even contain the type if it isn't referenced anywhere, so just constructing it and then ignoring it should be fine. If the users did manage to...

You mean third-party plugins using `performNonEmptyFieldsCheck`? Or third-party plugins relying on the non/existence of the type?

> thing (= thingByNodeId) --> ??? I think that `@omit all` on the table should remove all the root queries - not just the `allThings` list/connection, but also the `thingByPrimaryKey`...

Bikeshedding: should it be `single` and `all`, or `one` and `many`? Maybe even have both, use `@omit one` to omit the forward relation, and `@omit single` to omit the row-by-unique...

Yes, I don't want to change those. I'm suggesting: * `all`: `Query.allFoos`, `Query.allBars` * `single`: `Query.fooById(id)`, `Query.barById(id)`, and in the future maybe `Bar.fooBy…(…)` * `many`: `Bar.foos` * `one`: `Foo.bar`

Sorry I don't really have the resources right now to fix the PR