Will flask-sqlalchemy 3.0 make alchy unnecessary?

[lukeyeager]

@dgilland thanks for the very excellent blog post!

I have a question about this comment:

Just a heads up, in Flask-SQLAlchemy v3.0.0 (unreleased), they've added a "model_class" argument that will essentially make the recipe here unnecessary: https://github.com/mitsuhiko/flask-sqlalchemy/blob/7d65e2dc1f4e798f3234aaef01e615e3db319b05/flask_sqlalchemy/__init__.py#L728

You said that pallets-eco/flask-sqlalchemy#328 basically makes alchy and Flask-Alchy unnecessary, but after reading the long discussion at pallets-eco/flask-sqlalchemy#250, it sounds like there is more work to be done. Can you comment on how each of those pull requests relates to your blog post?

Thanks and sorry for the ignorance.

P.S. I also added a comment on the blog - feel free to respond to one or the other instead of both.

[dgilland]

I don't think I ever said that the changes to Flask-SQLAlchemy would make alchy unnecessary. I was referring to Flask-Alchy extension which was was primarily developed to take advantage of the work done in Flask-SQLAlchemy around session management within the Flask request/response cycle.

Alchy is a standalone ORM-session layer that extends functionality provided by SQLAlchemy without any dependence on a web framework. It was inspired by Flask-SQLAlchemy but has since gone beyond what Flask-SQLAlchemy provides.

ASIDE: I've pretty much stopped development of alchy in favor of its successor, sqlservice, which has taken a slightly different design approach while still trying to achieve some level of feature parity with alchy.

At the time when Flask-Alchy was created, there wasn't an easy way to provide your own declarative base model for use within the Flask-SQLAlchemy extension. You had to basically subclass Flask-SQLAlchemy and override where necessary.

The blog post that I wrote was in response to developers I worked with and questions I had seen on forums asking how to use Flask-SQLAlchemy without Flask. There seemed to be some misunderstanding/confusing about Flask-SQLAlchemy's role and how to extract some of its functionality out of the Flask specific items. While I think Flask-SQLAlchemy is great, I think it would have worked better as two libraries (one for improving upon SQLAlchemy and another as a much thinner integration layer between a SQLAlchemy session manager and Flask). Too many good features made their way into Flask-SQLAlchemy but then required that they could only be used with a Flask application context.

So I would say that once the custom model and query class features in Flask-SQLAlchemy are implemented, then the need for Flask-Alchy would no longer exist.

[lukeyeager]

Thanks for the quick, detailed answer! I'll take a look at sqlservice, too.