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

AbstractEntity and input #686

Closed
tasselchof opened this issue May 11, 2024 · 5 comments
Closed

AbstractEntity and input #686

tasselchof opened this issue May 11, 2024 · 5 comments

Comments

@tasselchof
Copy link

I'm currently working on a project where I'm dealing with abstract inputs and facing some challenges with annotation. I have an entity, let's call it AbstractUser, and several types of users inheriting from it, such as RegularUser and Employee. Additionally, there's another entity named Business, which can be owned by either a RegularUser or an Employee.

In my code, I have a method setUser(AbstractUser $user) which should accept an AbstractUser as a parameter. However, I encountered an issue where using AbstractUser as an input parameter isn't feasible because it's not a final class and cannot be instantiated. In my case it's Doctrine inheritance and annotated entities.

What is the right path in that case?

@oojacoboo
Copy link
Collaborator

oojacoboo commented May 11, 2024

So, input types don't support inheritance in GraphQL. I think you're going to have to annotate this with a union...

/** @param RegularUser|Employee $user */`

And actually, this might not work either, since polymorphic input types aren't implemented yet. See #238.

Assuming a PR isn't submitted for the above, which would be really great to have... another option would be using #[ExtendType] and implementing individual setters for each user child type/class.

@tasselchof
Copy link
Author

And actually, this might not work either, since polymorphic input types aren't implemented yet. See #238.

Just to confirm, this won't work - I tried this way and failed.

@tasselchof
Copy link
Author

The only other option would be using #[ExtendType] and implementing individual setters for each user child type/class.

Why in that case ExtendType is needed at all? If we have an individual setters we can just set it without ExtendType.

@oojacoboo
Copy link
Collaborator

oojacoboo commented May 13, 2024

ExtendType isn't needed. However, if you don't want to modify your domain model/entities for your public API, it's best to separate those concerns with extended types.

@tasselchof
Copy link
Author

ExtendType isn't needed. However, if you don't want to modify your domain model/entities for your public API, it's best to separate those concerns with extended types.

Oh yes, this makes sense. Thanks for clarifying. I have a little bit different structure so ExtendType won't work for me for that case and only will complicate things - it was easier to modify trait, that was adding this functionality.

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

No branches or pull requests

2 participants