I know there is no absolute solution for my question. I just want to
hear your suggestions and how you do this in your practice.
In which layer of the MVC-pattern are all the SQLAlchemy objects
located?
How do you realize this?
sqlalchemy is related to the M in MVC. You define models for your objects and then sqlalchemy is an ORM that saves your models to a relational database.
SQLAlchemy objects are really just queries for interacting with your relational database but in a way that allows you to use models in your application.
Miguel Grinberg has an excellent tutorial on how to use Flask, a python microframework, that goes through all the concepts of MVC including sqlalchemy
http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world
There is a python sqlalchemy tutorial, as well as many others available on the sqlalchemy site at:
http://www.sqlalchemy.org/library.html#pythonsqlalchemytutorial
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.
Recetly I've seen an app powered with django and mongodb as backend,thing is that app doesn't have a models.py file.All the datas are inserted directly in views.py.I Just need a little clarification about this particular things "Using django without models.py with mongodb."
models.py is the Django ORM way of inspecting a fixed relational schema and generating the relevant SQL code to initialize (or modify) the database. "ORM" stands for "Object-Relational Mapping".
Mongo is not relational, hence you don't need this type of schema.
(Of course, that can cause a lot of other problems if the needs of your project change later...)
But you don't need a relational schema since you're not using a relational DB.
A short answer
models.py is the ORM that comes free with django.
ORM relates your SQL schema into oopsy objects.
You can read more about ORM here-> https://en.wikipedia.org/wiki/Object-relational_mapping.
When using a noSQL, you can push objects directly into DB. So, you do not really need an ORM.
That said, whether to use it or not is a debatable part.
PS. even while using SQL, some people prefer other ORMs instead of django's built-in models.
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.
setup
A TurboGears2 project using ming as an ORM for mongodb. I'm used to working with relational databases and the Django ORM.
question
Ming claims to let to interact with mongodb like it's a relational database and a common thing to do in a relational database is sort a query by a property of a foreign key. With the Django ORM this is expressed with double underscores like so: MyModel.objects.all().order_by('user__username')
Is there an equivalent for this in ming?
I have never used ming, but they seem to have a sort method that you can add to a query, check it out here, not much in the form of documentation
I use mongoengine, it has great documentation and its very similar to the django ORM
When using django, I believe you can swap out the built-in orm for sqlalchemy (not sure how though?).
Are they both basically the same thing or there is a clear winner between the 2?
When using django, I believe you can swap out the built-in orm for sqlalchemy (not sure how though?).
You can use SQLAlchemy in your Django applications. That doesn't mean you can "swap" out the ORM though. Some of Django's built-in batteries would cease to work if you completely replace Django's ORM with SQLAlchemy. For instance the Admin app wouldn't work.
I have read about people using both. Django's ORM to get the batteries to work and SQLAlchemy to tackle complex SQL relationships and queries.
Are they both basically the same thing or there is a clear winner between the 2?
They are not the same thing. SQLAlchemy is more versatile than Django's ORM. For instance while Django's ORM tightly couples the business logic layer and the persistence layer into models, SQLAlchemy will let you keep them separate.
On the other hand SQLAlchemy has a steeper learning curve and would be an overkill for many projects. The existing migration tools for SQLAlchemy may not easily integrate with Django.
All said, I wouldn't presume to declare either a "winner". They are broadly similar tools but with their own strengths, weaknesses and best-fit situations.
While you are on the subject it wouldn't hurt to read this (dated but relevant) blog post about the short comings of the Django ORM and how it compares with SQLAlchemy.
SQLAlchemy is more powerful, but also more complex, than Django ORM.
Elixir provides an interface on top of SQLAlchemy that is closer to Django ORM in terms of complexity, but also lets you use constructs from SQLAlchemy if Elixir alone isn't enough. For example, I've found SQLAlchemy's AssociationProxy class to be useful on several occasions. You just drop an AssociationProxy field into an Elixir model class and you're good to go.