Benedikt Franke

I could see there being a config option that maps the names of pagination types to classes that implement their behaviour. The classes would have to implement a common interface...

I agree that what you are describing is seldomly the wanted behaviour. It *might* be used to attach and update a related model in one go. While i have not...

> How about to tweak update in such way, that for one-to-one relations, if id or primary key is not passed in input, model will be fetched from relation? Sounds...

> First, the search argument is not added to the list of search arguments if the value is empty. It is not added when the value is `null`, which in...

The issue I see is that queries may be written in a way to use Scout or database queries. Keep in mind that `@eq` can apply to both. ```graphql type...

Let's also consider this from a schema evolution perspective. We start with the following schema, not using Scout. ```graphql type Query { users(email: String @eq): [User!]! } ``` Clients query...

> unique fields for the search variants Probably the better way to go. The current approach is somewhat mysterious to clients and can result in runtime exceptions, e.g. https://github.com/nuwave/lighthouse/blob/6b0fddebcdb575ce08c5dd5ac884afa835b9a29d/src/Scout/ScoutEnhancer.php#L138 Laravel's...

Perhaps we can describe that behaviour in the `@search` docs?

I have never seen anything like that. Can you check the diff between the releases? https://github.com/webonyx/graphql-php/compare/v15.19.1...v15.20.0

How would this interact with the configuration `lighthouse.query_cache`? I presume the hash would only be available if `lighthouse.query_cache.enable` is `true`?