I am writing a library for Pyramid. One aspect involves the library being provided with a model class, then retrieving all instances of the model from the database. However, I am unable to interact with the DB without access to the session factory.
In Django this was taken care of behind the scenes. With Pyramid & SQLAlchemy this is not the case.
Is there a standard way for me to get hold of the current thread's DB Session within Pyramid, and without having any knowledge of how a particular project is setup (as this is a reusable library)?
PS. I'm still getting my head around this area of SQLAlchemy, so please excuse any confusion.
You could specify sqla session as attribute in inherited classes, like factory-boy does:
https://factoryboy.readthedocs.org/en/latest/orms.html?highlight=sqlalchemy#sqlalchemy
Another way is create interface and require to register sqlalchemy session in application registry as utility, before "config.include" your extension. Maybe pyramid_jinja2 will clarify this solution.
I recommend reading about
a convention to add session to the request object. Your library makes just an assumption about that and write that in your package docs.
http://blog.safaribooksonline.com/2014/01/07/building-pyramid-applications/
Global vs. Non-Global session
http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/database/sqlalchemy.html
A offical tutorial showing those concepts
http://docs.pylonsproject.org/projects/pyramid/en/master/quick_tutorial/databases.html
A lot of pyramid applications use the package zope.sqlalchemy to integrate application transaction management and DB session management. This approach is even recommended as one of many options by SQLAlchemy docs. Docs of zope.sqlalchemy are a bit confusing at least to me. The topic as a whole is a constant source of confusion to people starting with pyramid and thread-local sessions using SQLAlchemy.
To see a full-featured pyramid app that makes use of these packages look at ToDoPyramid - one of the sample application listed on pyramid docs pages
I cloned the project to make the database-related code at least more testable and readable to me. I found the concepts work very well - if the environment targetting the database is setup up properly.
Related
I noticed that most examples for accessing mysql from flask suggest using a plugin that calls init_app(app).
I was just wondering why that is as opposed to just using a mysql connector somewhere in your code as you need it?
Is it that flask does better resource management with request life cycles?
Using packages like flask-mysql or Flask-SQLAlchemy, they provided useful defaults and extra helpers that make it easier to accomplish common CRUD tasks.
All of such package are good at handling relationships between objects. You only need to create the objects and then the objects contain all the functions and helpers you needed to deal with the database, you don't have to implement such code by yourself and you don't need to worry about the performance of the queries.
I had worked on a Django project（I believe the theory in Flask is similar） and its ORM is really amazing, all i need to do is writing Models and encapsulate business logic. All CRUD commands are handled by the built-in ORM, as a developer we don't worry about the SQL statements.
Another benefit is that it makes database migration much easier. You can switch it from MySQL to PostgresSQL with minimal code modifications which will speed up development.
I am new to Flask and have noticed that there are two plugins that enable CRUD views and authorized login, Flask-Admin and Flask-AppBuilder.
These two features interest me along with nice Master-Detail views for my model, where I can see both the rows of the master table and the relevant details on the same screen.
Any idea which one to prefer? I see that Flask-AppBuilder has far more commits in Github, while Flask-Admin many more stars.
How to tell the difference, without spending too much time with the wrong choice?
I am the developer of Flask-AppBuilder, so maybe a strong bias here. I will try to give you my most honest view. I do not know Flask-Admin that much, so i will probably make some mistakes.
Flask-Admin and Flask-AppBuilder:
Will both give you an admin interface for Flask with bootstrap.
Will both make their best to get out of your way.
Will both help you develop Flask more Object Oriented style.
Will both let you override almost everything on the admin templates.
Will both support Babel.
Both inspired on Django-Admin.
Pros for Flask-AppBuilder:
Has a nicer look and feel (bias? maybe...).
Security has been taken care of for you, and supports out of the box, database, LDAP, OpenID, Web server integrated (REMOTE_USER), and in the near future OAuth too. Will let you extend the user model and security views.
Granular permissions, creates one permission for each web exposed method and action (you have to try it).
You can easily render Google graphs.
Smaller project, it's easier to request new features, and get your pull requests merged.
MasterDetail views and multiple views can be setup easily.
Backends: supports SQLAlchemy, MongoEngine, GenericInterface (you can integrate with your own builtin data still a bit beta).
Pros for Flask-Admin:
You have to assemble your own security (models, views, auth etc), it's ready though to integrate nicely with flask-security. This can be a pro or a con depending on what you want.
Builtin File Admin.
Bigger project with bigger community.
Backends: supports SQLAlchemy, GeoAlchemy, MongoEngine, Pewee and PyMongo.
Better support for MongoEngine (EmbeddedDocument, ListFields etc..).
On the overall i think Flask-Admin makes no assumptions at all like Flask, you have to code more, but this will let you be more free. Flask-AppBuilder makes some assumptions (on security), you will have to code much less, but some things can get on your way if your building very specific security models.
Hope this helps you and others, i tried my best to keep the bias out.
For me, master/detail is the major feature. That led me to use Flask AppBuilder to create ApiLogicServer:
With 1 command, create a database API, to unblock UI development. Also, a multi-page web app, to engage Business Users - early in the project. Declare logic with spreadsheet-like rules - 40X more concise than code, extensible with Python - for remarkable business agility.
Basically, I am trying to share as much database layer code as possible between a Flask application (for a REST API) and a non-Flask API.
Is it a good idea to use the same Flask-SQLAlchemy layer in both the pure Python API (intended to be imported in non-web Python applications) and in the REST API Flask daemon?
I guess another way to phrase, though I am not sure on the terminology, "how do I best share database model between Flask app and a separate Python import library?"
Or from another angle, is there any point in using Flask-SQLAlchemy in a Flask REST API, if you also want to share the SQL abstraction with an import library. Is it better then to use plain SQLAlchemy?
Use case: we have a large database with many tables, and want to build both a REST API (for customer access) and a Python import library (for performant internal tools) for accessing the database, but of course share as much code between them as possible.
Related:
Using Flask-SQLAlchemy in Blueprint models without reference to the app
What's your folder layout for a Flask app divided in modules?
SQLAlchemy with Flask -- hybrid models?
Using Flask-SQLAlchemy models out of a web context is a matter of creating a Flask application and call
app.test_request_context().push()
The point here is what you will do with your "non web" library.
If it's not a problem to have the whole Flask library installed when you need to use the library then there's no problem at all using it in that way.
If you plan to make performance improvements in the library data accessing code, like using different sessions, concurrency and such, then you're modifying your initial code so it's a totally different scenario. In this case a pure-SQLAlchemy approach might be better but it really depends on the differences between the two patterns.
Normally with models comes methods and using 2 different ORM patterns (Flask-SQLAlchemy wrapper models and pure SQLAlchemy) means duplicating code.
I have two apps that both access the same database. The first has clients connecting via TCP and writes to the db using SQLAlchemy. The second is a more typical webapp using Django. Both have read/write requirements.
I would like to unify the database access layer, but picking just SQLAlchemy or just Django is unattractive because:
I would like to use django auth, permissions, and maybe third party plugins, which require the Django ORM (correct me if I'm wrong).
For the first app, using SQLAlchemy (so far) is much simpler than trying to use the Django ORM outside of a Django app - it is a TCP/IP server app, not a HTTP/web app.
Are there any problems with mixing these two ORMs on the same database?
In which system (Django, SQLA) should I create the models, vs using some kind of introspection such as Django inspectdb?
Firstly - it's not very hard to use Django ORM outside a manage.py, WSGI handlers and other HTTP related stuff. You can use it any python script, but it needs some initialization (example).
Secondly - SQLA is a very powerfull tool and it's able to do stuff which is very hard to achive in Django ORM (like genuine polymorphism and polymorphic queries). If I had to choose, I'd personally choose to use Django ORM as a platform to create models, then manually map them in SQLA since it is much more flexibile and hopefully will be able to adopt. Which may not work in the opposite case.
Finally, since you can use Django ORM on both sides, and you just have to use a Django ORM because of the plugins, I suggest to abandon the SQLA. It's a powerfull tool, but also rather complicated. Having two different ORMs operating on one database may result in unexpected problems in the future and increases the complexity of your app, so it'll be harder to maintenance.
I'm building my first python app on app-engine and wondering if I should use Django or not.
What are the strong points of each? If you have references that support your answer, please post them. Maybe we can make a wiki out of this question.
Aral Balkan wrote a really nice piece addressing this very question. Its a year or so old, so take it with a grain of salt - I think that a lot more emphasis should be put on the awesomeness of django's Object-Relational-Model. Basically, IMHO, it all comes down to whether or not you have a preference for using DJango's object model (which I happen to).
If it's not a small project, I try to use Django. You can use the App Engine Patch (http://code.google.com/p/app-engine-patch/). However, the ORM cannot use Django's meaning your models.py will still be using GAE's Datastore.
One of the advantages of using Django on GAE is session management. GAE does not have a built-in session.
You won't be able to using most Django 3rd-party apps though especially those with model changes. I had to build my own tagging app for GAE.