You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
https://github.com/BerriAI/litellm uses prisma-client-py and it happens to define some fields that start with model_ and this causes Pydantic to complain with a bunch of warnings like this:
UserWarning: Field "model_max_budget" in LiteLLM_BudgetTable
has conflict with protected namespace "model_".
Suggested solution
It would be nice to be able to get rid of these warnings. To do this the generated code would have to have:
model_config['protected_namespaces'] = ()
or something similar.
Ideally, this would be configurable so that most projects don't have to turn off this checking.
One possible way to solve this is if prisma-client-py had a config option like pyantic_disable_protected_namespaces that would cause it to add the necessary code. PR: #983
Alternatives
Another option is a more general feature that allows adding any arbitrary Python code to the generated class. This would be more powerful but probably much harder to implement.
Additional context
The text was updated successfully, but these errors were encountered:
msabramo
added a commit
to msabramo/prisma-client-py
that referenced
this issue
Jul 24, 2024
Problem
https://github.com/BerriAI/litellm uses prisma-client-py and it happens to define some fields that start with
model_
and this causes Pydantic to complain with a bunch of warnings like this:Suggested solution
It would be nice to be able to get rid of these warnings. To do this the generated code would have to have:
or something similar.
Ideally, this would be configurable so that most projects don't have to turn off this checking.
One possible way to solve this is if prisma-client-py had a config option like
pyantic_disable_protected_namespaces
that would cause it to add the necessary code. PR: #983Alternatives
Another option is a more general feature that allows adding any arbitrary Python code to the generated class. This would be more powerful but probably much harder to implement.
Additional context
The text was updated successfully, but these errors were encountered: