-
-
Notifications
You must be signed in to change notification settings - Fork 69
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
Add support for selecting fields #19
Comments
An interesting potential solution would be to make use of PEP 646 which would mean returning tuples instead of BaseModels though. |
Selecting fields is really helpful, hope this feature will be implemented soon, thank you. |
Is model field selection available ? |
@lekhnath Yes the solution mentioned in the "Type checker agnostic" section has been implemented, see these docs for more information: https://prisma-client-py.readthedocs.io/en/stable/reference/selecting-fields/ |
Problem
A crucial part of modern and performant ORMs is the ability to choose what fields are returned, Prisma Client Python is currently missing this feature.
Mypy solution
As we have a mypy plugin we can dynamically modify types on the fly, this means we would be able to make use of a more ergonomic solution.
The mypy plugin would then dynamically remove the
Optional
from the model for every field that is selected, we might also be able to remove the fields that aren't selected although I don't know if this is possible.The downside to a solution like this is that unreachable code will not trigger an error when type checking with a type checker other than mypy, e.g.
Will pass type checks although the if block will never be ran.
EDIT: A potential solution for the above would be to not use optional and instead use our own custom type, e.g. maybe something like
PrismaMaybeUnset
. This has its own downsides though.EDIT: I also think we may also want to support setting a "default include" value so that relations will always be fetched unless explicitly given
False
. This will not change the generated types and they will still beOptional[T]
.Type checker agnostic solution
After #59 is implemented the query builder should only select the fields that are present on the given
BaseModel
.This would mean that users could generate partial types and then easily use them to select certain fields.
Or create models by themselves
This will make typing generic functions to process models more difficult, for example, the following function would not accept custom models.:
It could however be modified to accept objects with the correct properties by using a
Protocol
.The text was updated successfully, but these errors were encountered: