It appears that not everyone knows that in python you can create classes dynamically without metaclasses. I'll show an example of how to do it.
So we've learned how to use custom QuerySet to chain requests:
Article.objects.old().public()Now we need to make it work for related objects:
user.articles.old().public()
This is done using use_for_related_fields, but it needs a little trick. Thing is that in django related managers are initialized without arguments, and our QuerySetManager takes argument - queryset class.
objects = QuerySetManager(MyQuerySet)We have to update QuerySetManager in such a way, that will allow setting queryset as class field:
class QuerySetManager(models.Manager):
use_for_related_fields = True
queryset_class = QuerySet
def get_query_set(self):
return self.queryset_class(self.model, using=self._db)
def __getattr__(self, key):
return getattr(self.get_query_set(), key)In order to use this manager, we have to create a sublcass and set queryset_class:
class MyManager(QuerySetManager):
queryset_class = MyQuerySetIt's not fun to create such class every time. So we'll write a function that does it for us:
def queryset_manager(qs_class):
class Manager(QuerySetManager):
queryset_class = qs_class
return Manager()Now it's enough to write:
objects = queryset_manager(MyQuerySet)Subscribe for the news and updates
This article offers key insights into the ISTQB certification and shares a proven preparation strategy to help candidates succeed.
Earlier in our previous article "Improve efficiency of your SELECT queries" we discussed ways to profile and optimize the performance of SELECT queries. However, to write complex yet efficient SQL queries, there is a thing to remember about.
Django ORM is a very abstract and flexible API. But if you do not know exactly how it works, you will likely end up with slow and heavy views, if you have not already. So, this article provides practical solutions to N+1 and high loading time issues. For clarity, I will create a simple view that demonstrates common ORM query problems and shows frequently used practices.
In my current project I had a task to use twitter API. Twitter uses OAuth for authentication, which is pretty dreary. To avoid fiddling with it all the time, I've moved authentication to decorator. If key is available - nothing happens, just view is launched as usual. It's convenient that there's no need for additional twitter settings in user profile. Code is in article.
For local project settings, I use old trick with settings_local file:try:from settings_local import \*except ImportError:passSo in settings_local.py we can override variables from settings.py. I didn't know how to supplement them. For example how to add line to INSTALLED_APPS without copying whole list.Yesterday I finally understood that I can import settings from settings_local:# settings_local.pyfrom settings import \*INSTALLED_APPS += (# ...)
Everybody knows about permalink, but it's usually used only in get_absolute_url. I prefer to use it for all related model urls.class Event(models.Model):# ...@models.permalinkdef edit_url(self):return ('event_edit', (self.pk, ))And then in template:<a href="{{ event.edit_url }}">Редактировать событие</a>