Exclude a computed field #7114
Replies: 9 comments 11 replies
-
|
I face the same issue and I think it is a bug. Computed fields should not be serialized if the repr on the field is set to False. |
Beta Was this translation helpful? Give feedback.
-
|
What is the point of excluding a computed field from the serialization output? If you don't want it to be included, you can use a simple from pydantic import BaseModel, computed_field
class Model(BaseModel):
a: int
@computed_field
@property
def b(self) -> int:
return self.a 1
Model(a=1).model_dump(exclude="b")
#> {'a': 1} |
Beta Was this translation helpful? Give feedback.
-
|
No, because you cannot use setters in that case.
|
Beta Was this translation helpful? Give feedback.
-
|
I've updated my comment. Could you please provide an example of what you are trying to achieve? |
Beta Was this translation helpful? Give feedback.
-
|
Well, if you want to know why your suggestion of using the exclude in the model_dump method does not fly, it could make sense to reread all the discussions of the need to be able to exclude a field during serialization in the model definition instead of putting it in the model_dump or dict() method in v1. The moment you have models containing fields pointing to other models which then again point to other models in their model definition this quickly becomes as nightmare. I fail to understand why computed fields should be treated differently in this respect than any other fields. |
Beta Was this translation helpful? Give feedback.
-
|
If you always want the computed field to be excluded, then only using If you still want to have the computed field included in the JSON Schema? Or apply validation on the setter (then using pydantic validators is the solution)? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, this is new in V2, in V1 this was not possible. That is excellent news actually, thanks! |
Beta Was this translation helpful? Give feedback.
-
|
@Viicos It would make sense to add this to the documentation though. If we now also solve this issue we would have at last a perfect @Property implementation, I look forward to it! |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Hum, seems like you inverted the two examples? Doing |
Beta Was this translation helpful? Give feedback.
-
|
I'll have to get back to this code - all I know is that swapping them made the |
Beta Was this translation helpful? Give feedback.
-
|
Right, updated the example, thanks 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
It is useful when you want to save the dumped object into database. But currently there seems no easy way to do this. |
Beta Was this translation helpful? Give feedback.
-
|
This recently came up in #10625, iirc (because people downvote without giving an explanation), #7114 (comment) is not enough because it can be tedious to track every computed field to exclude? |
Beta Was this translation helpful? Give feedback.
-
|
The problem with comment is yeah, it gets a bit gnarly with deeply nested models. |
Beta Was this translation helpful? Give feedback.
-
I think it gets downvoted because the original question is:
Then the comment starts off:
That does not really address the original question. I assume that the question is about an API endpoint that includes a field that isn't part of the ORM model. An endpoint may handle both input and output data from that field and serialize it to/from other fields in the ORM model. In my note, which resolved my own issue (but now marked off-topic), I was using |
Beta Was this translation helpful? Give feedback.
-
Because before providing a solution I'd like to know if this is really needed (as I want to avoid xy problems). The goal of the |
Beta Was this translation helpful? Give feedback.
-
|
@Viicos can't speak for anyone else, but yeah, that's the exact scenario I ran into this evening. We have some computed fields that represent materialized object relationships, and we want to include those when accessed via our API, but exclude them when we're dumping out to a persistence layer. That way, we can instantiate a serializer from a cached JSON representation, and always retrieve the object relationships at query time. We probably could just stash them in the persistence layer and overwrite them every time, but it does become somewhat troublesome for deep nesting. What I ended up doing was creating a subclass of BaseModel that includes a |
Beta Was this translation helpful? Give feedback.
-
|
I have a similar case. I have a pydantic model and I want to have some properties I can cache, but have nothing to do with dumping the model. Just a function that caches itself and I can call it without parenthesis for backwards compatibility. This is the code: from __future__ import annotations
import json
from typing import Any, Literal
from pydantic import computed_field
from pydantic.dataclasses import dataclass
@dataclass(slots=True, frozen=True)
class Response:
request: Request
url: str
status_code: int
body: list[int] | None = None # bytes
headers: dict[str, str] | None = None
@computed_field # type: ignore[misc]
@property
def content(self) -> str | None:
if self.body is None:
msg = 'Response body is not available. There is no content to decode.'
logging.api.log(logging.WARNING, msg)
return None
encoding: str | None = None
if self.headers is None:
msg = 'Response headers are not available. Cannot determine encoding. Assuming utf-8.'
logging.api.log(logging.WARNING, msg)
else:
content_type = self.headers.get('content-type', None) or self.headers.get('Content-Type', None)
if content_type is None:
msg = 'Content-Type header is not available. Cannot determine encoding. Assuming utf-8.'
logging.api.log(logging.WARNING, msg)
else:
content_type = content_type.lower()
charset = content_type.split('charset=')[-1]
if charset != content_type:
encoding = charset
elif 'application/json' in content_type:
# NOTE: The default encoding for JSON is utf-8 as per RFC 4627.
encoding = 'utf-8'
else:
msg = 'Content-Type header does not contain a charset. Cannot determine encoding. Assuming utf-8.'
logging.api.log(logging.WARNING, msg)
if encoding is None:
encoding = 'utf-8'
body_bytes = bytes(self.body)
return body_bytes.decode(encoding)
@computed_field # type: ignore[misc]
@property
def content_deserialized(self) -> Any | None:
if self.content is None:
return None
try:
return json.loads(self.content)
except json.JSONDecodeError:
msg = 'Response content is not a valid JSON.'
logging.api.log(logging.WARNING, msg)
return None
@computed_field # type: ignore[misc]
@property
def content_json(self) -> dict[str, Any] | None:
if self.content_deserialized is None:
return None
if not isinstance(self.content_deserialized, dict):
msg = 'Response content is not a JSON map object.'
logging.api.log(logging.WARNING, msg)
return None
return self.content_deserialized
@computed_field # type: ignore[misc]
@property
def content_list(self) -> list[Any] | None:
if self.content_deserialized is None:
return None
if not isinstance(self.content_deserialized, list):
msg = 'Response content is not a JSON list object.'
logging.api.log(logging.WARNING, msg)
return None
return self.content_deserializedAs it is, it does not as I expected it. |
Beta Was this translation helpful? Give feedback.
-
|
@Viicos can we reopen this? AFAICT there's no (good) solution for this:
|
Beta Was this translation helpful? Give feedback.
-
Does someone know how to exclude a computed field from model_dump() in the model definition?
The only option I see now is writing my own model_serializer but I feel there must be a better way?
Beta Was this translation helpful? Give feedback.
All reactions