Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support collection in setter #11

Open
bartvanhoutte opened this issue May 16, 2018 · 4 comments
Open

Support collection in setter #11

bartvanhoutte opened this issue May 16, 2018 · 4 comments

Comments

@bartvanhoutte
Copy link

I've started using this library recently and love it so far, I have a small support request though. :-)

Currently, I have a mutation that allows a user to create a Company.

'createCompany' => [
    'type' => Type::nonNull($types->get(Company::class)),
    'args' => [
        'input' => Type::nonNull($types->getInput(Company::class)),
    ],
    'resolve' => function ($root, $args) use ($resolver) {
        return $resolver->createObject(Company::class, $args['input']);
    },
],

The Company model holds a Collection (Doctrine) of objects of the Entity Contact. Retrieving the Collection through GraphQL is not a problem:

/**
  * @return \Doctrine\Common\Collections\Collection
  * @\GraphQL\Doctrine\Annotation\Field(type="?Contact[]")
  */
public function getContacts() : Collection
{
    return $this->contacts;
}

I have annotated Company::getContacts() using the Field annotation as per the documentation (this works, but am I doing this the right way?).

Setting the collection however, does not work. This code:

/**
  * @param \Doctrine\Common\Collections\Collection $contacts
  * @\GraphQL\Doctrine\Annotation\Input(type="Contact[]")
  */
public function setContacts(Collection $contacts)
{
    $this->contacts = $contacts;
}

Results in this error:

Type for parameter `$contacts` for method `Company::setContacts()` must be an instance of `GraphQL\\Type\\Definition\\InputType`, but was `GraphQL\\Type\\Definition\\ObjectType`. Use `@API\\Input` annotation to specify a custom InputType.

What am I doing wrong?

Thanks in advance!

PS: I'm using ecodev/graphql-doctrine:2.0.1 and webonyx/graphql-php:v0.11.6.

@PowerKiKi
Copy link
Member

You most likely did nothing wrong. The case you describe is not specifically supported yet, so it is very likely that what you experience is the result of a bug-ish behavior.

What would you expect to happen from the API user point of view ? Give an array of ID ?

Then from the resolver point of view, what would you expect to receive ? a Doctrine Collection automatically filled with entities loaded from the array of ID ?

Would you like to open a PR to add a failing unit tests to the project that would illustrate your use-case ? You could probably add a User::setPosts() method in the existing class.

@bartvanhoutte
Copy link
Author

What would you expect to happen from the API user point of view ? Give an array of ID ?

Yes, sounds good.

Then from the resolver point of view, what would you expect to receive ? a Doctrine Collection automatically filled with entities loaded from the array of ID ?

Yes, sounds good. Maybe out of scope for this issue: could this result in an out-of-memory exception and if yes, how do we handle it?

I've forked & branched the repository, but do you have any pointers on where to get started with writing a test for this? I've added setPosts to User but I'm not sure on how to continue. Do we need something like \GraphQL\GraphQL\StarWarsQueryTest (webonyx/graphql-php) or is there another way to test this behavior?

@PowerKiKi
Copy link
Member

If you added a setter, then I would expect \GraphQLTests\Doctrine\InputTypesTest::testCanGetInputTypes() to fail already because generate schema would most likely not equals the expectation (in tests/data/PostInput.graphqls).

Then for the resolver part, I'm not quite sure yet, but it would most likely be similar to \GraphQL\Doctrine\Definition\EntityIDType and \GraphQL\Doctrine\Definition\EntityID...

Let's start with your failing test first, create a work-in-progress PR with whatever you have and we can work on that...

@PowerKiKi PowerKiKi changed the title InputType vs ObjectType in setter Support collection in setter May 22, 2018
@jamesmoey
Copy link

Needed this functionality. I will start to implement this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants