I'm curious and excited. Have you talked about the differences between this and TortoiseORM yet? The latter has the big advantage of having an api familiar to Django users.
In short, what motivated you to write your own rather than "bless" one of the existing ones?
I see the approach that this isn't exactly an orm, it's more of an api wrapper around it (SQLalchemy in that case), is that correct?
SQLModel isn't its own totally new thing so much as an abstraction that lets you create models that are both SQLAlchemy models as well as Pydantic models, simultaneously. If you use Pydantic, or want to be using it with your models, this sounds pretty great. Right now shoehorning the same kind of functionality into other frameworks can be a bit of a pain.
I do love Tortoise though, and it is what I am using currently -- but also one thing I'm currently battling with it is its approach to working with Pydantic. So I'll be giving this a try.
Yep, I wanted to build it on top of SQLAlchemy to inherit all it's robustness and to be compatible with it, as it has the biggest widespread. SQLAlchemy now supports async too, so SQLModel inherits that as well.
And in particular, other libraries have done a great job, but I wanted to take advantage of the features that editors can provide, with autocompletion, inline errors, etc. SQLModel has lots of tricks to provide the best developer experience possible, e.g. autocompletion while creating a new model instance.
In short, what motivated you to write your own rather than "bless" one of the existing ones?
I see the approach that this isn't exactly an orm, it's more of an api wrapper around it (SQLalchemy in that case), is that correct?