Open tiangolo opened 1 year ago
This is great news! So excited to start using these new features. I'm curious how you are planning in integrating Alembic?
Is the goal to support both Pydantic v1 and v2 and SQL Alchemy v1 and v2? Or only v1+v1 and v2+v2? The combination of both will become difficult.
@AntonDeMeester @tiangolo Only support SQLAlchemy v1.4 with 2.0-style and v2.0?
Is there a branch of this project or a starter template for using FastAPI latest + SQLAlchemy 2 + Pydantic 2?
I'm starting a new project with FastAPI latest + SQLAlchemy 2 and I'm not sure what would be the right way to set it up? Should I just avoid SQLModel altogether?
@hyperknot Try https://github.com/tiangolo/sqlmodel/pull/632
Thanks @honglei.
I've also found
I'll personally not use SQLModel. It introduces way too much logic for a simple type checking functionality for me.
Duplicating a small amount of code in the codebase is much more maintainable than introducing an external dependency with a lot of logic involved.
You can help me ensure each existing PR is in shape (has tests, solves the problem, etc.)
π«‘
So glad to see signs of life in this amazing project.
We are using fast API with SQL Model for our microservices. And planning to add Llama index which needs SQLAlchemy above 1.4.41. But does not support by current SQL Model versions (required: >=1.4.17,<=1.4.41).
@tiangolo Need your kind help.
Are the items on the roadmaps features you plan to implement yourself, or are they open for PRs?
In any case, this is really exciting! I can't wait to be able to use a Pydantic v2 + SQLModel (with all the great SQLAlchemy 2 features) + FastAPI stack!
Fully agree. Have other stuff already upgraded to pydantic 2.x.x and SqlAlchemy 2.x.x and cannot introduce SQLModel to the mix.
From: Matthieu LAURENT @.> Sent: Tuesday, 24 October 2023 15:21 To: tiangolo/sqlmodel @.> Cc: Subscribed @.***> Subject: Re: [tiangolo/sqlmodel] π Roadmap (Issue #654)
Are the items on the roadmaps features you plan to implement yourself, or are they open for PRs?
In any case, this is really exciting! I can't wait to be able to use a Pydantic v2 + SQLModel (with all the great SQLAlchemy 2 features) + FastAPI stack!
β Reply to this email directly, view it on GitHubhttps://github.com/tiangolo/sqlmodel/issues/654#issuecomment-1777192911, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALUWECMEPO3K523RRZFZ3DYA66DLAVCNFSM6AAAAAA5TK2VBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZXGE4TEOJRGE. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>
Take a look at this.
Since the dev dependency, FastAPI, no longer supports Python 3.7 from version 0.104.0 onwards, will SQLModel also need to drop support for Python 3.7 in the future? If so, it would likely be a massive undertaking. It should be included in the roadmap together.
When dealing with relational models,sqlalchemy only needs to define relationships on one side,sqlmodel needs to define relationships on both sides, and the complexity of the model class is very difficult to deal with. The screen full of relationships makes my brain a little hot, especially the many-to-many relationships, even if the model class is written according to the documentation, it becomes extremely complex.
I am looking forward for SQLAlchemy v2 support. This should enable ClickHouse columnar storage.
Sorry if this is adding noise βΒ just noticing the next items in the roadmap are somewhat achieved in #632 (open since August). Any chance we could understand the project's thinking wrt when something like that might be merged or reworked?
I'm curious what are the tricky parts in SQLAlchemy and pydantic 2.0.0 versions...
Now Ready for Pydantic 2.0 π
Update: Since SQLModel version 0.0.14, both Pydantic V1 and v2 are now supported ππ
Since the dev dependency, FastAPI, no longer supports Python 3.7 from version 0.104.0 onwards, will SQLModel also need to drop support for Python 3.7 in the future? If so, it would likely be a massive undertaking. It should be included in the roadmap together.
Pydantic and SQLAlchemy have already dropped support for Python 3.7.
https://github.com/pydantic/pydantic/commit/0564c0d2c90c8dd98ac7cf88b7b6ab68fdef256c https://github.com/sqlalchemy/sqlalchemy/commit/4da59c6f534371d8c76cd728e8a459018e9112b6
Additionally, Python 3.7 reached its End of Life (EOL) a few months ago, so it's time to say goodbye.
https://devguide.python.org/versions/
Some things that may need to be done
@tiangolo Could you please provide any updates on this? I've begun a new FastAPI project, and I'm uncertain whether I should build upon the SQLModel project or stay with SQLAlchemy. What are your long term plans with this project?
@cay89 This and the cookiecutter
template are under development; from @tjeaneric, it looks like the sqlalchemy
and pydantic
support is done, but the alembic
support hasn't been released yet.
You should be able to use sqlmodel==0.0.14
and manually generate migrations for your fastapi
project: alembic init --template async alembic
. You will need to manually edit the generated alembic.ini
and alembic/env.py
to use sqlmodel
's metadata object. This was possible in 0.0.8
before the sqlalchemy
relationship
support broke around sqlalchemy==1.4.x
. Things are still sort of in limbo for official design patterns when considering a backend stack consisting of fastapi
, sqlalchemy
, pydantic
, and alembic
. This integration has been tracking between the authors of these projects for more than a few years. The official design patterns for backend work are right around the corner.
Are we going to get an update on the Async docs ?
Hello team, Amazing work, What is the ETA on Async milestone? Can we bump it up before pydantic? @tiangolo
@manish181192 I haven't seen an "ETA"; some of the remaining work is staged as PRs:
I haven't seen any work covering typer
usage in sqlmodel
.
Integrated migrations (using Alembic).
Hi @tiangolo, are #689 and #635 ready to be merged?
Hi! I just came across #63 and I was surprised this would not work out of the box, is this kind of behaviour considered at any stage on the roadmap?
Kind of related is #468 , I have it almost sorted out setting the engine with json serializer and deserializer but now I just noticed that if I change a field in the model the update woin't go through when committing.
Thanks!
Hi @tiangolo, are https://github.com/tiangolo/sqlmodel/pull/689 and https://github.com/tiangolo/sqlmodel/pull/635 ready to be merged?
@tiangolo Any update for the roadmap?
Hey @tiangolo! Thanks again for your awesome work :).
Do you have any ideas on when you could have something done for
Integrated migrations (using Alembic).
?
I guess I am not alone waiting for this marvelous feature :).
All the best!!
Hey @tiangolo! Thanks again for your awesome work :).
Do you have any ideas on when you could have something done for
Integrated migrations (using Alembic).
?
I guess I am not alone waiting for this marvelous feature :).
All the best!!
it's already working
Is it possible to merge https://github.com/miguelgrinberg/alchemical project into current one?
Hey @tiangolo! Thanks again for your awesome work :). Do you have any ideas on when you could have something done for
Integrated migrations (using Alembic).
? I guess I am not alone waiting for this marvelous feature :). All the best!!
it's already working
Is it documented somewhere? I tried to integrate alembic into sqlmodel. I had to tweak the setup.py in unholy ways, was not a smooth and pleasant experience. I guess @tiangolo had in mind to do this very doc and smoothing? :)
@tepelbaum I know it's two months later, but I wound up having to work on a minimal implementation of sqlmodel and alembic, so I published it to github. I'd actually be interested to keep maintaining this example or something like it, if it's helpful.
migration is seems already finished in official template repo full-stack-fastapi-template and here is the README
Description
This is a tentative roadmap, I will update it as things evolve. Some things might be discarded, others might be added later. I didn't want to make it fully public as it could raise expectations, but it seems it would be more beneficial for the community to know all the ideas and objectives.
Work on this is alternated (and sometimes mixed) with work on Typer, SQLModel, Asyncer, and others.
Answering questions, issues, and PRs is also intermixed with this, but as in some cases one of these features would solve several issues or questions, or potentially solve something done by one or more PRs, in many cases I focus on this a bit more than on answering specific issues, questions, PRs.
Maintenance
The word "maintenance" or "maintainer" doesn't have a very strict definition, and it probably varies a lot from perspective.
A lot of the work related to maintaining FastAPI is done by contributors by answering questions, reviewing PRs, etc.
You can help me ensure each existing PR is in shape (has tests, solves the problem, etc.). Make sure you filter out the translation PRs (most of them) unless you speak the language and can review them.
Security
When there are security issues, those are handled with the highest priority. Those are normally not handled in issues and PRs but in emails, it's not public until the security disclosure is made, in most cases (always, up to now) with the version that fixes them.
Roadmap
Now, here's the current high-level tentative roadmap:
All this is intermixed with reviews for PRs, issues, and discussions.