This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
FastAPI 0.67.0 new dataclass related features conflict with some aspects of new SQLAlchemy dataclass-style model mapping #3616
Comments
I think this is caused by the same dataclass serialization issue as #3608 . |
Could you check if my patch in PR #3607 fixes the issue for you? |
I have also experienced this issue this week. It caused a huge slowdown in generating the openapi schema in 0.64 but broke when I updated to 0.67. The slowdown in schema generation seemed to come from A pydantic field has a However I've been meaning to report this as a bug for the last day or two. A longer term fix is of course needed, but whether this is in FastAPI or Pydantic is maybe a matter for discussion. |
@himbeles , thank you! Unfortunately your fix won't work since in my case such a statement is problematic: obj_dict = dataclasses.asdict(obj) It grabs all |
I have no hope that this is going to be fixed someday, especially for reason that it could affect new |
I've run into the same issue, and have created a pull request that addresses it for me (PR #4094) - I'm not 100% sure about the approach though, let me know what you think. |
@Lunrtick , I think a bool flag like that is not a good solution. It would be nicer to call |
@AlexanderPodorov I agree - it's definitely not the cleanest solution. I thought it'd make sense because we'd be opting in to a "legacy" feature, but it'd also mean FastAPI would need to support that going forward. Perhaps we could emulate the There may be better ways to allow specifying this option though... Is it Pythonic to have a custom dunder property? In my codebase, this change only requires me to update my base class, from which all my SQLAlchemy models inherit. |
@Lunrtick yes, I think it's a bit better. And yes, I think it's fine to have a custom dunder class attribute. SQLAlchemy relies on them too ( |
Is this ever going to get fixed? A rather big issue I would say |
hi guys, this has been affecting us as well |
Interesting, I would think that the main problem here would be that SQLAlchemy supports a bit of dataclasses, but it doesn't support So, I would think that the problem is not with dataclasses, and not necessarily even with FastAPI, but with the quirk that SQLAlchemy is doing its best to support dataclasses while not being made to do so, so it can only do so much, while still modifying the class and attributes in several ways. I see there are some possible approaches, like the I'm not sure what's the best approach here. I hope to provide a way to configure how things are serialized and converted internally at some point, and that would allow customizing these things. I also made SQLModel to solve this kind of problems and avoid code duplication: https://sqlmodel.tiangolo.com/ , you can also check if that works for you. About just parsing directly from the |
@tiangolo , thanks for your great work and FastAPI! I don't see a good way of address this issue either.
I would avoid calling I'm now returning Pydantic models (parsed from SQLA dataclasses) from my endpoints. |
Thanks for the input @AlexanderPodorov! Yep, it seems SQLAlchemy supports several parts of dataclasses, but it seems it specifically doesn't support (at least not fully)
The problem with this is that it would work only for the specific case where the I hope to, in some future release, allow customizing how to serialize return values. This would probably allow overriding this functionality to accommodate this particular use case, for example. On the other hand, Pydantic V2 will have first class support for other types apart from models. Maybe that could help with these use cases too. I guess it would also be nice to have support in SQLAlchemy for |
Thanks for the comments @tiangolo ! SQLAlchemy actually supports Yes, I understand there could be some complications with other use cases of I'm doubtful about having some config class specifying what to serialize. Technically we could have the same object, but we want to serialize it differently in different situations. If you want, I can close this issue or keep it open until we get better solution. Thanks! |
I'm fairly new to SQLAlchemy, but I've been testing SQLAlchemy 2.0, and I've noticed that the new declarative model definitions result in model instances where So it seems this issue may affect all models in SQLAlchemy 2.0, not just dataclass models. I've had to comment out the code responsible for dict conversion so that my models can be properly parsed as Pydantic models with Edit: I was using the |
Thanks for the comments! Yep, if you solved your use case you can close the issue @AlexanderPodorov 🤓 |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
First Check
Commit to Help
Example Code
Description
Example code works if
fastapi==0.66.1
and it does not work iffastapi==0.67.0
.Open a browser, hit
POST /users/
endpoint and create a userExpected behaviour: User is created and displayed successfully.
Current behavior: User is created successfully (check in DB), but is not displayed successfully due to serialization errors.
Most likely the reason is in the new dataclass related features of FastAPI 0.67.0. Since the new-style database models are dataclasses as well, therefore they are affected too. As far as I can see if an instance is the dataclass, then FastAPI makes a
dict
(dataclasses.asdict(res)
) out of instance before doing serialization.It has two issues: first, if a dataclass has a property, it won't be serialized; second, if a dataclass has a relationship with
lazy="raise"
(means we should load this relationship explicitly), it is actually accessed and caused SQLAlchemy's exception.Technically, if we let
pydantic
to serialize this dataclass, we won't get any of those issues. I assume it was the case for previous versions of FastAPI.Here are a few links:
https://docs.sqlalchemy.org/en/14/orm/mapping_styles.html#orm-declarative-dataclasses-declarative-table
https://docs.sqlalchemy.org/en/14/orm/loading_relationships.html#prevent-lazy-with-raiseload
Operating System
Windows
Operating System Details
No response
FastAPI Version
0.67.0
Python Version
3.9.6
Additional Context
No response
The text was updated successfully, but these errors were encountered: