"Weak" BaseModel #2533
Adamantish
started this conversation in
Feature Request
Replies: 1 comment
-
If this idea really feels icky another option could be a Such an option might also be helpful for those who just want the complete list of errors rather than just the first found. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Firstly, I'm happy to try writing this PR if it seems helpful.
Background
We're using Pydantic in Django Ninja which is basically FastAPI but for Django. Both of these frameworks are great but lack a simple feature that would make me sleep easier at night.
In production only I'd like to be able to set an env var something like
If this happens in prod I'd want to log an error, sound all the alarms, and probably add to the response an extra
errors
attr but I still want to return a best effort response to the client (perhaps not on all endpoints but that could be configurable). I'll explain later why that's such a desirable feature.The issue, as I see it, is that these frameworks can't implement such a feature because once Pydantic finds an attribute it can't parse, it aborts immediately.
Proposal
I'm proposing a
WeakBaseModel
which upon encountering a parsing error will record the problem in a list and then continue to the next attribute. The model object has the list of errors as an attached attribute (not automatically to be serialized).When validating data coming in, it's always good to be strict for the well-known reasons and unless you have a client programming error, you're only affecting one user.
However, if your data is not already in the most perfect and validated state, this rule is kind of reversed for outgoing responses especially for not-so stateful web clients.
Use-case
At my company we cut a corner for a quick release and we converted an
int
id column to astring
so that a separate feature could use the table. We coerce thosestring
s back toint
s for the pre-existing API...You can see where this is going now.By convention that API will not ever fetch one of the alphanumeric ids but we haven't yet properly enforced that. If I hadn't noticed that we need to loosen the type on the model/separate these fields properly then it would take only value misplaced by one of our admin users then Pydantic would cause our most critical endpoint to go down for most users (The endpoint returns a largish lot of initial config).
The alternative - one mismanageable value out of thousands which the client probably won't use but for which we log an immediate alert - is usually far preferable.
The intention would be to use this "weak" approach only in prod so that bugs stay hard to accidentally ship. Perhaps that implies instead, a
pydantic_weak_check
attribute on the existingBaseModel
so it's natural to use such a pattern. Or maybe aWeakenableBaseModel
so as to stay totally clear in backwards-compat terms.Overarching "Why"
In summary, we're using pydantic and now trying to type-hint everywhere because we want to sleep easier at night. This new and so far unavoidable catastrophic failure mode is the only way in which it doesn't deliver. At core, Python is still dynamic so questionable typing practices will still exist a lot in the wild. It's nice for this not to add more brittleness than necessary.
What are your thoughts?
Beta Was this translation helpful? Give feedback.
All reactions