-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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 |
My problem isn't with the type checker but with the actual runtime (don't want to have to call I can do an absolutely hideous but I find that a little scary |
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 |
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. |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: