Open Bugs and Future of SQLModel

[BenediktAllendorf]

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.

[dandiep]

I have similar questions!

[richieadler]

@BenediktAllendorf you may noticed that many of the requested changes have been merged. Maybe closing the question would be useful?

[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”.

[daniil-berg]

@BenediktAllendorf I absolutely agree.

I don't even think the "bus factor" is the main issue here. That is just a hypothetical worst-case scenario. It's that after a certain point the project inevitably begins to suffer, if only one person is solely responsible for everything.

I totally understand @tiangolo's concern with the quality of the project and how it can potentially decline, if other people (who may have different standards than him) gain permission to make decisions and affect its course. I would feel the same way.

But this problem is not unique to software projects. Whenever any project grows beyond a certain point, there comes a time when the "owner" is faced with the option of installing a "2nd layer of management", so to speak, or continuing the "one-man-show". The problem is that once you start down that first path, a whole new can of worms is opened - management... People management. And the overlap between people who love developing software and people who love managing people is arguably not that great.

However, the alternative can potentially cause greater damage to the project - paradoxically - than managing people, who occasionally mess up, need to be briefed or directed or replaced. Because beyond a certain point, the project becomes unmanageable by a single person.

Now, I don't know @tiangolo personally. I have no idea about his inclinations, ideals or goals. With the impact he has had already and the size of FastAPI etc., I am sure that he has thought about these things extensively already. I don't want to presume anything. I got nothing but respect for him.

I just wanted to add my 2 cents because I do believe in this project and would like to see it thrive. Sorry about the rant.

[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.