Raw Sqlalchemy about flask-debugtoolbar HOT 12 OPEN

I have a similar issue, the panel always shows 0 queries and appears to be inactive (it can't be clicked). I am not sure if that is what you meant. I tried different ways of importing and initializing sqlalchemy without success.

from flask-debugtoolbar.

Flask-SQLAlchemy has a special hook that records queries during the session. See here, here, and here. Flask-Debugtoolbar uses this hook to populate the panel. See here.

If you are not using Flask-SQLAlchemy, you will need to do something similar to record and read back queries, and write a custom panel to display it. Submit a pull request with your solution, as it would obviously be useful to multiple people.

from flask-debugtoolbar.

Oh I see. Thank you for the reply, I guess it is easier to switch to the flask-sqlalchemy since I am early in the development.

from flask-debugtoolbar.

👍

from flask-debugtoolbar.

So, one of the issues here seems to be primarily documentation related. The docs don't explain that you need to use the Flask-SQLAlchemy extension, and so some people are understandably confused when their queries don't show up. This could be addressed by adding more info to the docs, and also a warning in the panel itself if it detects that the Flask extension is not being used.

The other, that I'd like to understand better, is when people are aware of the Flask-SQLAlchemy extension, but would prefer not to use it. What are the issues with Flask-SQLAlchemy that are motivating you not to use it? I know that Flask-SQLAlchemy adds a couple Flask-specific things like the "Model.query" helper attribute that some people may avoid for compatibility with other non-Flask usage, although it seems like it's possible to just use the session-management aspect without the others.

I don't want to stifle use-cases that I don't yet understand, but generally it seems like most apps are simplified by using Flask-SQLAlchemy. So if it's mostly just an issue of documentation, I'd prefer to focus on that and keep both this extension, and users' apps simpler by just using the existing Flask-SQLAlchemy support.

from flask-debugtoolbar.

I think you should rely on Flask-SQLAlchemy exactly as you do now (and make it a proper optional requirement for the project installable with pip install flaskdebugtoolbar[sqlalchemy]), but do not limit people that want to use models declared in plain SQLAlchemy.

The API of Flask-SQLAlchemy is not a superset of the SQLAlchemy API, and therefore limits you in some ways that SQLAlchemy does not (engine configuration for example has to go through Flask app configuration, something that is a hindrance in my use-case). It's also a matter of documentation; I prefer to stick to SQLAlchemy documentation instead of having to switch between the two to figure out how to use something. In general I found Flask-SQLAlchemy only a distraction and not an added value.

That's not to say that Flask-SQLAlchemy does not come with a few useful features, especially for the debugtoobar (like counting queries). This can still be used while having models declared in plain SQLAlchemy. My pull-request implements all of the above.

from flask-debugtoolbar.

Yes, with Flask-SQLAlchemy you need to configure the engine through the Flask config. However besides that, I don't think you need to use any Flask-SQLAlchemy specific APIs if you prefer not to. I find the Flask-SQLAlchemy shortcuts useful for simplifying the code, but you could ignore them and just use the SQLAlchemy APIs and documentation directly.

Is it possible to provide an example of how you're setting up the engine that doesn't work well with Flask-SQLAlchemy? I'm trying to get a better feel for when someone else might encounter the same need to create the engine directly.

from flask-debugtoolbar.

Engine is configured through Flask config, and then models declared through the db.Model which couples them to the engine which lies behind the db (unlike SQLAlchemy where models are decoupled from the engine, -1 point even here),

Nitpicking aside, this is the very simple case where I found having to use Flask-SQLAlchemy problematic: My db models and engine are in a python package independent from the Flask app (independent from anything else actually). This package is used by several python processes, also independent from each other: 1) my Flask web app, 2) my 2nd and 3rd other web apps (cubes and eve), 3) by the celery task queue, 4) by various other scheduled and manually invoked python scripts, 5)by the alembic db migration script. You can see having to couple the db/engine with my Flask app is a very counter-productive way to architect this system.

There also other API related issues. For example I am using multiple MetaData objects to group tables. Does Flask-SQLAlchemy support this kind of thing? It is not immediately apparent how to do this, and I would have to waste time reading through its documentation/code to figure out if it's even possible and how it works. This is my general feeling; I have to go through another API layer that only adds more complexity and no value.

from flask-debugtoolbar.

Over at the Flask-SQLAlchemy repo, we recognize that there are too many things coupled to specific behavior. There is ongoing work to decouple the session, engine, and metadata. The session is actually more problematic than the engine, as it's what's selecting the engine in the first place. Model shouldn't be an issue (and you can use other metadata in any given session) unless you want to use FSQLA's __bind__ support.

The proper way for the Toolbar to support other SQLAlchemy configurations is to provide its own event handlers registered on a session to record the necessary debug info.

from flask-debugtoolbar.

Has anyone made a debug panel that uses "raw" SQLalchemy? I also don't like the way that Flask-SQLAlchemy forces me to couple my db package to the web app.

from flask-debugtoolbar.

I also prefer raw SQLAlchemy due to the coupling (access the DB outside of Flask). I have compiled almost perfect configuration-based workaround. I can see the queries and their duration, their resultset and EXPLAIN but the Context is not correct. See #96 for an example app using this approach.

from flask-debugtoolbar.

I updated the merge conflict, docs and a few things from the @dtheodor pull request into a new pull request at #110

What do you think @jeffwidman ?

from flask-debugtoolbar.