Will flask-sqlalchemy 3.0 make alchy unnecessary? about alchy

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