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
Related
I am using sqlite (development stage) database for my django project. I would like to store a dictionary field in a model. In this respect, i would like to use django-hstore field in my model.
My question is, can i use django-hstore dictionary field in my model even though i am using sqlite as my database?
As per my understanding django-hstore can be used along with PostgreSQL (Correct me if i am wrong). Any suggestion in the right direction is highly appreciated. Thank you.
hstore is specific to Postgres. It won't work on sqlite.
If you just want to store JSON, and don't need to search within it, then you can use one of the many third-party JSONField implementations.
I have a few databases in MongoDB that I want to create models for dynamically, since there are many databases and I cannot do it manually. Questions:
What should my models.py look like? (Does inspectdb work with mongodb databases or only SQL based dbs?)
Since the database models are created dynamically, how do I code the serializer class to return the dynamic fields?
Thanks in advance.
Django supports an object-relational mapper, that is aimed at traditional relational databases. While there are a number of mongodb packages for Django, none of them support inspectdb to construct your models. Either way, inspectdb is a kludge designed as a one of process to help a one-of migratation away from a legacy system, i.e. you'd build your models.py file once and never run inspectdb again. This is not what you want to do, as you seem to want dynamic models that can be added or altered at runtime.
On the bright side, Django MongoDB Engine has some support for arbitrary embedded models within pre-defined models. But even then they don't seem too supportive of it:
As you can see, generic embedded models add a lot of overhead that bloats up your data records. If you want to use them anyway, here’s how you’d do it...
In summary, try to build your models as best you can to actually match your requirements. If you know nothing about your models ahead of production, then perhaps Django isn't the right solution for you.
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 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
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.