Benedikt Franke

Probably related to https://github.com/nuwave/lighthouse/pull/1390 A PR with a failing test case in https://github.com/nuwave/lighthouse/blob/master/tests/Integration/Schema/Directives/CountDirectiveDBTest.php should be a great start for a fix.

@tlaverdure right, thank you. @pkatuwal please try `@count` and report back with results. Given we have test cases for this functionality and it is working for others, i am closing...

I like the idea of nesting the operator and value within an input object equal to the field name, that does indeed allow for better type safety. I can see...

I think the potential for a naming conflict is very low, we could just accept that for ergonomic reasons. The operators Lighthouse already has (`AND`, `OR` - and once we...

> Still not sure about isNull/isNotNull, probably they still will use yes. How about: ```graphql enum Is { NULL NOT_NULL } ```

The next major version of Lighthouse will probably be PHP 7.4+, so we won't be able to do a copy-paste integration anytime soon. I am happy to let @LastDragon-ru experiment...

Great writeup! In terms of implementation, we can probably use a validation rule for it that mirrors the built-in rules of `webonyx/graphql-php`. A good source of inspiration could be https://github.com/webonyx/graphql-php/blob/master/src/Validator/Rules/QueryComplexity.php

Technically, this can be done by constraining the `SELECT` to the requested fields. The fourth resolver argument `ResolveInfo` can be used to know which fields a client selected. There are...

```php public function __invoke($root, array $args, GraphQLContext $context, ResolveInfo $resolveInfo) { $resolveInfo->getFieldSelection(); $resolveInfo->lookAhead(); // TODO use the information from those methods to SELECT only the given fields } ```

https://lighthouse-php.com/master/the-basics/fields.html