| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Simple code example to check (in the details)
Detailsfrom datetime import datetime
from sqlmodel import DateTime, Field, SQLModel, create_engine
class A(SQLModel):
created_at: datetime = Field(sa_type=DateTime(timezone=False))
engine = create_engine("sqlite:///")
SQLModel.metadata.create_all(engine)Running mypy gives
error: No overload variant of "Field" matches argument type "DateTime" [call-overload]
on master and
Success: no issues found in 1 source file
after applying this fix
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
See #1345 (review)
Sorry, something went wrong.
|
Thanks for approval! Who is responsible for merging this, what are the rules in this repo? |
Sorry, something went wrong.
Only Sebastian can merge it. I already forwarded it to him. We should just wait |
Sorry, something went wrong.
|
I have resolved conflicts here. I see you guys made some patch releases recently, hope this change can make it into one of them 🙃 |
Sorry, something went wrong.
|
was hitting this error when using sa_type, thanks for keeping it updated |
Sorry, something went wrong.
|
It would be nice to get it merged though 😅 |
Sorry, something went wrong.
|
Hey @tiangolo, gently bumping this. It's been open about a year now, has an LGTM from @YuriiMotov, and @svlandeg mentioned back in September she'd forwarded it to you for merging. To recap the issue:
Worth noting this is really a bug fix, not a feature. It's currently labeled as feature, but the code already does the right thing, this PR just corrects the type signature to match. Might be worth relabeling! Totally understand if it's just buried under everything else, I didn't want it to get lost. Thanks for all the incredible work you do on FastAPI and SQLModel (and friends) :) |
Sorry, something went wrong.
|
Thanks for the fix and for keeping this PR updated! During final review, I found a subtle distinction: SQLAlchemy’s positional Column arguments also accept SchemaEventTarget for other schema objects, while sa_type should accept only SQLAlchemy type classes or instances. I’ve put together #2095 with that narrower annotation, explicit type_ passing, and regression tests. It addresses the issue you identified here, so I’m closing this PR in favor of that implementation. Thank you again for your contribution, and sorry this took so long to resolve! ☕ |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Note
When I was writing description for this PR, I found another discussion started for just the same issue I was experiencing with mypy, so this changes are basically fixing the issue described here
Using sa_type and sa_column_kwargs instead of just sa_column can benefit when using inheritance for classes derived from SQLModel as it was suggested here.
If sa_column is not specified and sa_type is provided, it will be passed as a second, type argumnet to sqlalchemy.Column instance. If you would check sqlalchemy.Column construction definition, it looks as following:
Note the __type_pos argument with Union[_TypeEngineArgument[_T], SchemaEventTarget] where
So, from technical perspective you can pass not only the subclass of TypeEngine, e.g. SQLAlchemy's sqltype such as String, Integer, DateTime, JSON etc, but also an instance of this type.
I was trying for JSONB(none_as_null=True) and String(50) and it worked just fine, alembic migrations were generated correctly, only mypy was arguing for type mismatch with call-overload issue.
To fix mypy error, we can update type annotation for sqlmodel.main.Field.sa_type to support also an instantiated SQLAlchemy's sqltype to match those of sqlalchemy.Column
Related discussions: