Open Bugs and Future of SQLModel

TLDR; Is SQLModel actively maintained and developed? @tiangolo

The current version (0.0.6) is from last year, and I’m wondering about the project’s status. There are several open issues and reoccurring “basic” topics, e.g., not being able to use uuids (#25), having to use a pinned and outdated version of SQLAlchemy (#315, #386, #379, #383, …), or using workarounds for Enums (#24, #164, #165, …). Those problems have proposed solutions and open Pull Requests, but they are neither reviewed nor merged. (For some reason, those issues are labelled “questions” even though they should be “bugs”.)

I’m not only posting this to complain, but I must question whether to use SQLModel in this state. I’d offer to help, but apparently, it’s not the lack of work power (see all the open PRs).

Is there any roadmap, planning, or somewhat reliable information about the future of SQLModel? Both SQLAlchemy and Pydantic are working on “v2” of their projects. Is this somehow related (as in, SQLModel is waiting for that)?

I feel bad abusing the issue form like this, but I didn’t know how/where else to address this.

[BenediktAllendorf]

@richieadler I thought about that, but while the specific technical aspects are solved, there isn’t an answer to the general topic of plans/roadmaps/handling of bugs. @tiangolo talks about the “bus factor” here: https://youtu.be/BTCtKWpNoRI?t=4062, and I feel like this is not fully worked out yet.

Let me be clear: I appreciate and admire all the necessary technical knowledge to implement and maintain something like SQModel. But I also think it’s significant enough to have some “community structure” - because it seems that nobody knew the project’s status for the last half year.

For example, the dependency to SQLAlchemy is now pinned so that after the next but one version, we need another SQLModel update to have the most current. (The update to “1.4.41” will be allowed, but no version after that.) SQLAlchemy is released more often than SQMoldel, and having the newest version might be crucial, so this seems like a problem.

In the talk, @tiangolo talks about ensuring the code quality, and I get that he wants to keep managing the merge requests. But maybe there should be people “officially” helping to prepare those? Or perhaps them having the possibility to ping him like, “this bug is nasty; you need to have a look”.

[antont]

Let me be clear: I appreciate and admire all the necessary technical knowledge to implement and maintain something like SQModel. But I also think it’s significant enough to have some “community structure” - because it seems that nobody knew the project’s status for the last half year.

I don’t think it’s a huge deal as SQLModel is so small, and limited in scope. AFAIK it does not have any large development needs, as it is just a clever glue between Pydantic and SA.

Tiangolo told, during recent maintenance, that it’s helpful for him that folks answer questions, submit fixes, PRs, test those etc. We can do that without official structure, I guess reactions and comments help to see how tested some fix is etc.

Sure, it was a little horrible for a while that the project was like abandoned, and we also had to maintain a fork with some fixes, but it was also ok. I think it’s all fine going forward given tiangolo is available and does maintenance every once in a while at least. Community seems nice and some folks very knowledgeable here, and the whole SQLAlchemy crowd is out there for more.