when should I write methods in the model itself and when in the model manager?
is it like all methods to get something should be written in manager and others in model
There's a simple difference. Model methods act on a single instance. Manager methods create queries to act on multiple instances.
Related
I am building soft-deletion functionality for my Django project. I have implemented this using a custom model manager (i.e. performing an initial filter on get_queryset(), plus overriding Model / Manager / QuerySet delete().
Django documentation (1.11):
If you use custom Manager objects, take note that the first Manager Django encounters (in the order in which they’re defined in the model) has a special status. Django interprets the first Manager defined in a class as the “default” Manager, and several parts of Django (including dumpdata) will use that Manager exclusively for that model. As a result, it’s a good idea to be careful in your choice of default manager in order to avoid a situation where overriding get_queryset() results in an inability to retrieve objects you’d like to work with.
My soft delete-honouring manager is currently my model's default manager (first manager declared on the model class). It's also assigned to objects.
This is convenient for me as a lot of Django code uses the default model manager (e.g. MultipleObjectMixin.get_queryset() if your MultipleObjectMixin-inheriting View just has the model attribute defined).
However the fact that dumpdata also uses the custom model manager has scared me off, and has me thinking about other unknown unintended consequences of setting the default model manager. In the event that I perform a manage.py dumpdata, I'd want my soft-deleted models to be contained in the dump. So I am beginning to doubt myself regarding my choice in overriding the default model manager to filter down the available records.
At the same time, I appreciate the convenience that setting the default model manager is giving me (zero-effort support for generic CBVs.etc), which I want to maintain if possible.
What's the best way to approach this?
As per this documentation, if you run ./manage.py dumpdata -a or ./manage.py dumpdata --all, then it will dump data using default manager instead of custom manager. If you want to use your default manager instead of custom manager(without changing in models) then you can try like this:
objects = YourModel._base_manager
objects.all()
Newbie here! Here is my question: In Open Object Framework that is used by Odoo it is possible for a model to inherit both fields and methods from multiple modules. For example a Product model in the context of a Warehouse Management System does not have the same attributes and functionality as a Product model in the context of a Sales Management System.
Consider a Product model defined in a WMS module and a Product model (please note the same name) defined in a SMS module, where the basic attributes and functionality are defined in the WMS.Product.
Is it possible to achieve such an inheritance mechanism with SqlAlchemy so that when calling create_all the Product model that is created contains all the fields and methods that are defined in every module?
In django documentation, it say that we can retrieve data entry as below
entry = Entry.objects.get(pk=1)
Entry is a model class in models.py. I tried to find the declaration of objects, but I can't find its declaration in manager.py, just know it is a instance of Manager. So, where is the declaration of objects? Does it represent a set of Entry instances?
When you define model, you extend Model class from django.db.models module.
It will provide default model manager in objects property.
If you want to define custom model manager, you can do it by subclassing django.db.models.Manager class.
Look at the docs how to do that: https://docs.djangoproject.com/en/1.11/topics/db/managers/
Add methods to custom model managers to if you want to manipulate with the collection of data. If you manipulate with single row, add method to your model.
It's defined in ModelBase, which is the metaclass for model classes. See https://github.com/django/django/blob/master/django/db/models/base.py#L360
It seems like much of what can be done by a custom Queryset can be accomplished by a model Manager. So why use custom Querysets instead of model Managers?
Custom querysets allow for chaining methods, while custom managers only let you access defined methods directly from the manager. If you need to expose methods from the manager and the queryset, you can use Queryset.as_manager.
Take a look at: https://docs.djangoproject.com/en/1.9/topics/db/managers/#create-manager-with-queryset-methods
I am aware that you can get a reference to an existing model from within another model by using self.pool.get('my_model')
My question is, how can I get a reference to a model from a Python class that does NOT extend 'Model'?
In that case you will have to import the class like a normal Python class, writing in your .py file:
from your_path_class import YourClass
And then you will be able to work with it:
Yourclass.any_method()
By the way, self.pool.get('your model') in Odoo 8 API is self.env['your_model'].
It's pretty basic and simple any python class can be called from it's name space, so call your class from namespace and instanciate the class.
Even Model class or any class inherited from Model can be called and instanciated like this.
Self.pool is just orm cache to access framework persistent layer.
Bests