Implement support for querying soft deleted elements

[lorado]

• Added or updated tests
• Added Docs for all relevant versions
• Updated the changelog

Related Issue/Intent

Resolves #100

Changes

• New enum Trash is defined. Possible values are ONLY, WITH and WITHOUT
• @find, @all and @paginate directives searches for argument of enum type Trash and applies defined filter to fetch either onlyTrashed, withTrashed or withoutTrashed

Breaking changes

There are no breaking changes

Additional Note

I currently implemented this feature only for @find, @all and @paginate directives. I guess that probably it would be cool to be able to define such an argument on related items too? Didn't look for the possible implementation, but what you think?

UPDATE

Reworked to @softDeletes directive, #937 (comment)

[spawnia]

Nice feature, you did a great job with the implementation.

I am still pondering on the best way to add a trashed filter to a query. We could do it through a schema-manipulating field directive, such as:

foos(): [Foo!]! @all @softDeletes

[lorado]

Nice feature, you did a great job with the implementation.

Thanks!

I am still pondering on the best way to add a trashed filter to a query. We could do it through a schema-manipulating field directive, such as:

foos(): [Foo!]! @all @softDeletes

I was also thinking about it. But as people already discussed here I thought it is the idea people would like =)

Currently solution is simple, but it might be not really clear, that adding Trash argument will be managed by lighthouse, as there is no visible directive in the schema definition.

I didn't write a custom directive till now, so don't know how would I implement your solution...

[spawnia]

@softDeletes would be a FieldManipulator, with the sole purpose to add an argument to the field. The transformed field would look like:

foos(trashed: Trash @trash): [Foo!]! @all

The @trash directive is just a regular ArgBuilderDirective.

[lorado]

Ok, I'll give a try today ;)

[lorado]

So, just got ready new implementation via directives. Actually this approach is much better, as we don't have to duplicate code and take care of, where this parameter could also be entered (e.g. on relation fields).

By now it works also with @hasMany and I guess all other relation directives. With less code I was able to achieve more cases. Profit 😄

One thing took me much time... I didn't figure out, why is it happened... As I updated my tests, I had something like this:

        $this->graphQL('
        {
            users {
                tasks(trashed: ONLY) {
                    id
                    name
                }
            }
        }
        ')->assertJson(...);

        $this->graphQL('
        {
            users {
               tasks(trashed: WITH) {
                    id
                }
            }
        }
        ')->assertJsonCount(3, 'data.users.0.tasks')

As you can see, these queries are different - different trashed value and even different data set. But the second request became always the same response, as first query - with only trashed tasks. And this happened ONLY in this nested structure. Tests with plain structure work fine (if you wish you can take a look at other tests). I though it is my implementation fault, but why the plain fields work? I also tried to run test with disabled cache, but it didn't help.

What helped - using aliases in graphql Query. This way results were always fetched correctly.

I don't know, if this bug also appear in real world, we will see...

[lorado]

@spawnia Should I do anything else, so this PR gets merged? I am trying to keep it all the time up to date... Would be nice if this feature could be released next week.

[lorado]

I made changes as you wanted

P.s. First time in this situation on github. Was not sure what happens, when I click on "submit" :D

[spawnia]

Hey @lorado working it in right now.

I am changing the behaviour when using the directives upon models that do not use SoftDeletes to throw instead of silently doing nothing.

[spawnia]

The issue with multiple queries in a single test is caused by some caching mechanism within Laravel's HTTP helpers. It should not happen in production, as PHP dies after each request.

[lorado]

The issue with multiple queries in a single test is caused by some caching mechanism within Laravel's HTTP helpers. It should not happen in production, as PHP dies after each request.

Oh ok. Yea, I guessed that there is somewhere cache, but didn't know which one. Thanks for explanation. Your changes looks great. I was also thinking about throwing an exception, but was not sure if it is a good idea.

[lorado]

Offtopic. Just for me to know how to work with github PR: Is it possible somehow to pull your changes you made in this PR?

[spawnia]

Offtopic. Just for me to know how to work this github PR: Is it possible somehow to pull your changes you made in this PR?

You can just pull them. I committed to your branch.

[spawnia]

@lorado can you hop into Slack for a quick chat? https://join.slack.com/t/lighthouse-php/shared_invite/enQtMzc1NzQwNTUxMjk3LWI1ZDQ1YWM1NmM2MmQ0NTU0NGNjZWFkMTJhY2VjMDAwZmMyZDFlZTc1Mjc3ZGY0MWM1Y2Q5MWNjYmJmYWJkYmU