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

Is it possible to instantiate the mapped strawberry classes? #14

Open
mattalbr opened this issue Mar 27, 2023 · 6 comments
Open

Is it possible to instantiate the mapped strawberry classes? #14

mattalbr opened this issue Mar 27, 2023 · 6 comments

Comments

@mattalbr
Copy link
Contributor

mattalbr commented Mar 27, 2023

I'm struggling with some complicated resolvers for the fact that, from my understanding, the whole execution flow works without ever instantiating the strawberry types, just leveraging the fact that the fields are static methods and strawberry will take care of the execution for us.

I'd like to be more rigorous about typing and convert the return sqlalchemy models to the strawberry types before resolvers return them. Right now, the generated init seems to take every single field, and they're all positional arguments, making it hugely inconvenient. Is there a "copy constructor" of sorts to convert from ORM to Strawberry? If not, would it be hard to make one?

Upvote & Fund

  • We're using Polar.sh so you can upvote and help fund this issue.
  • We receive the funding once the issue is completed & confirmed by you.
  • Thank you in advance for helping prioritize & fund our backlog.
Fund with Polar
@TimDumol
Copy link
Collaborator

Possibly you can explicitly invoke Strawberry's field resolution (it's been a while since I've taken a look, but hopefully it's in the docs, otherwise you can dig into the source), but I'd personally just typing.cast() it.

@mattalbr
Copy link
Contributor Author

mattalbr commented Mar 28, 2023

My problem isn't with the type checker but with the actual runtime (don't want to have to call StrawberryType.my_field(obj) everywhere, would much rather do obj.my_field()), so typing.cast won't do it.

I can do an absolutely hideous
result.__class__ = StrawberryType

but I find that a little scary

@mattalbr
Copy link
Contributor Author

Also, it seems like the autogenerated relationship resolver returns the model class instead of the strawberry class. Would love if it would return the strawberry class instead

@mattalbr
Copy link
Contributor Author

@TimDumol

I got working locally a version of strawberry-sqlalchemy-mapper that generates a from_row classmethod and returns strawberry types instead of sqlalchemy types from each resolver. The resolvers can also handle a model being passed in as self for backwards compatibility, but I think the documentation should encourage returning strawberry types (else the static methods get confusing fast).

If I sent you a PR, do you think you could help me with some of the finer details? Namely, I don't know what a mapped interface is (as opposed to a type) and wouldn't be surprised if this fails for that case. I wouldn't be surprised if there are some other edge cases I missed.

@TimDumol
Copy link
Collaborator

Hey @mattalbr -- sorry, been fairly busy recently. I'm not entirely certain what you're trying to achieve, but I believe a PR would help communicate that more effectively, so go for it.

@mattalbr
Copy link
Contributor Author

Sure thing! Sent the pull request, with a bunch of my thoughts in the description. Please take a look when you get a chance, and we can discuss/iterate over there.

#16

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