In order to be able to find broken records in the database, it would be great to be able to get full data of invalid item in the ValidationError traceback output.
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
pydantic version: 1.4
pydantic compiled: True
install path: /home/oklymenko/.virtualenvs/zakaz-commerceman-api/lib/python3.8/site-packages/pydantic
python version: 3.8.0 (default, Oct 21 2019, 13:32:28) [GCC 7.4.0]
platform: Linux-5.3.0-46-generic-x86_64-with-glibc2.27
optional deps. installed: []
from datetime import datetime
from pydantic import BaseModel, ValidationError
class SomeResponse(BaseModel):
class Config:
invalid_model_full_data = True
id: str
name: str
start_datetime: datetime
end_datetime: datetime
imvalid_data = {
"id": "123123",
"name": ["some_name"],
"start_datetime": 4,
"end_datetime": 2,
}
try:
SomeResponse(**imvalid_data)
except ValidationError as e:
print(e)
"""
1 validation error for SomeResponse
name
str type expected (type=type_error.str)
full_data
{
"id": "123123",
"name": ["some_name"],
"start_datetime": 4,
"end_datetime": 2,
}
"""
...
I think that's reasonable if it's easy to implement.
Let's do it as part of v2.
I like this idea.
At the risk of bikeshedding, I'd like to see this as an attribute on the ValidationError raised (original/raw_data maybe?), rather than by default in the message, as I may be validating large objects and don't want to see the whole thing in every case.
If it's adding anything to the default message string, I would presume it would be under a "received" or "got" key and displayed next to/at the end of the expected line.
total agree, that's why I didn't add it earlier, but I can see many scenarios where access to that data would be useful.
@samuelcolvin @StephenBrown2 guys, please, review
Most helpful comment
total agree, that's why I didn't add it earlier, but I can see many scenarios where access to that data would be useful.