-
-
Notifications
You must be signed in to change notification settings - Fork 510
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
default_factory doesn't work #3517
Comments
Fixing this will potentially be a breaking change 🤔 @coady what do you think of this issue? |
I don't think this can be supported (and still be compliant with the spec). GraphQL defaults are statically in the schema. type Mutation {
update1(fields: MyInputType!): String!
update2(fields: MyInputType!): String!
}
input MyInputType {
field1: String = "318fbf6e-73b6-40eb-932f-0b66ba935b75"
}
type Query {
hello: String!
} Another issue is that the client sending an explicit null is valid and semantically different. So if field1 in (None, UNSET):
field1 = uuid_pkg.uuid4() That may seem like a workaround, but is actually the only correct implementation. |
@patrick91 @coady hi! Thanks for your answers. Yes, now it's the only way with The main reason why I'm thinking about another implementation is pydantic models, I really like to use example: import strawberry
from pydantic import BaseModel, field
class PydanticModel(BaseModel):
field1: str | None = Field(default_factory=uuid_pkg.uuid4)
@strawberry.experimental.pydantic.input(PydanticModel)
class MyInputType():
field1: str | None = strawberry.UNSET # not works here By the way I sent daft PR with overriding #3469 |
@patrick91 and also can I ask in what situations then we need to use |
I'm not sure to be honest, I'll need to think about this a bit I do think it might be a flaw, or at least something surprising, so maybe we need to reconsider it |
I do understand the schema's default value issue, but I do agree with this comment. I actually had to do workaround a similar issue on strawberry-resources when exporting form data for the field as a dynamic default value would not actually make sense there. So my vote would be to actually change the behavior to fix this issue, specially since we still are 0.x =P, and mention as a "possible breaking change" in the changelog, mentioning the use of |
just throwing out some ideas to make the change less painful
option 1 could also have a codemod to make the update easier 😊 |
@coady sorry to ping you again, but do you use default_factory for defaults in the schema level? 😊 what's your use case exactly? |
The only use I'm aware of (and use) is for mutables, as dataclasses requires. Any valid value is a valid default value, including I'd be happy with a cleaner alternative for mutables. This is forbidden (but is valid GraphQL): q: list[float] = [0.5] So instead I have to use q: list[float] = (0.5,) # type: ignore which mypy complains about. |
I think we could do option 2 for the time being |
Hi!
I use default_factory to initialize my variable, but variable always returns the same result. It seems like default_factory doesn't work and it returns always the same result of function.
Here is example to reproduce:
https://play.strawberry.rocks/?gist=a7a5e62ffe4e68696b44456398d11104
Upvote & Fund
The text was updated successfully, but these errors were encountered: