Интернет нового века

Я всё продолжаю по рабочим и не только нуждам ковырять наследование моделей, поэтому как и обещал - то ли ещё есть!

• Очередной сюрприз ждал меня, когда я обновляя свой блог-движок под текущий транк. Я обнаружил сломанным блок "Архив" из-за того, что метод dates() перестал возвращать уникальные значения на месяца, а выдавал мне всё подряд. Я сильно удивился. Но пофиксил всё при помощи, в последнее время моего любимого, set. Да, костыль, но ковырять дальше пока желания нет.

• Далее уже по рабочим нуждам обновления тест наборы для приложения, проявились некоторые особенности работы fixtures. Для примера, допустим у нас есть такие связанные наследованием модели:

  class Base( models.Model ):
     field1 = models.IntegerField( default = 10 )
     # + неявное поле id
  
  class Derived( Base ):
     field2 = models.IntegerField( default = 1 )
     # + неявное поле base_ptr
  

  1. Сериализатор дампит модель наследника целиком, т.е. со всеми полями в том числе и родителей.

  2. При загрузке модели родителей не могут подцепить свой первичный ключ, а просто делают новый INSERT, получая тем самым новый id. Потом этот ...

Читать далее

Наконец-то! Уверен, что я не один воскликнул это слово, когда узнал что долгожданная queryset-refactor ветка влилась в транк и теперь ORM в джанго стал ещё лучше и удобней! Этого момента ждали долга, поскольку это один из самых больших шагов по направлению к 1.0 версии джанги. Итак, что же мы получили.

Начну с основных изменения уже имеющегося функционала:

• Указание сортировки по при-join-ненным моделям теперь стало более логичным и совпадает с фильтрами lookup'ов. Просто пример:

  Order.objects.all().order_by( "product__price" )
  

• Обновлена реализация __iter__ метода queryset'a. И не грузит все строки результат в память сразу.

• Особенно меня радует: сделана нормальная обработка None значения в lookup'ах. Т.е. если раньше приходилось писать писать воркэраунды для случая когда селект осуществлялся по NULL значениям, например так:

  if value is None:
      queryset = queryset.filter( field__isnull = True )
  else:
      queryset = queryset.filter( field = value )
  

  То теперь эта проверка лишняя не нужна. Ура!)

• Есть ещё некоторое количество изменений, но они на низко уровне и на прямую ...

Читать далее

Знак вопроса в заголовке заметили? Не спроста он там. Поскольку если в вопросе индексирования я утверждал, что выбрать есть из чего и это маленькая но проблема (как и всегда чем больше вариантов, тем больше головной боли по поводу выбора лучшего), то тут, на мой взгляд, всё более очевидно.

Но вы можете мне возразить, что мол приложений, которые позволяют использовать мультиязычный динамический контент, несколько и из них тоже нужно выбирать. На как оказывается выбирать не из чего по сути.

Итак, сейчас существует несколько реализаций для мультиязычности контента базы:

• transdb
• django-multilingual
• i18ndynamic

Есть ещё, как бонус, ряд приложений, которые позволяют редактировать gettext *.po файлы через стандартную джанговскую админку:

• django-rosetta
• django-i18tor

И во всех группах есть свои явные лидеры по удобству и функциональности.

Начнем разбор первой группы, где приложения для предоставления перевода контента из базы данных.

Первым на растерзание попадает transdb. Идея хранить перевод поля модели в виде сериализованных питон-словаря - только мне кажется бредовой? Как делать выборки по отдельным языкам? Как поиск осуществлять ...

Читать далее

Проблема выбора реализации для индексирования/поиска на сайте, поднятая мною недавно, пришла к своему разрешению. Как я уже говорил, остановился я на djapian. Но в том виде, в котором было данное приложение, его использовать было практически невозможно.

Решил немножко подкрутить там гайки и обтесать под свои нужды. Но поскольку изменений накопилось много, то я завел отдельный проект для моей ветки. Назвал я его просто и без затей django-xapian. И конечно же выкладываю в открытый доступ свои наработки. Вот домашняя страничка проекта http://webnewage.org/projects/p/django-xapian/

Основные изменения по сравнению с оригиналом:

• Код подтянут до транка джанги
• Исправлен NameError, который ставил крест на использовании оригинала:)
• Объекты обрабатываются только при срабатывании пользовательского триггера, а не просто по событию
• Перенесен сервис индексировани из отдельно скрипта в команду manage.py
• Оптимизирован процесс индексирования - убраны лишние действия, которые выполнял исходный скрипт, не отфильтровывая неактуальные уже изменения в объектах.
• Убрана махинация с неймспейсами
• Добавлена возможность индексирования не только непосредственно полей данных модели и но ...

Читать далее

Часто нужно в шаблоне вывести какой-то конфигурационный параметр. Нет, не тот который в settings.py, а тот который хранится в базе. Ну например префикс заголовка страниц, содержимое мета-тега в head или ещё какую-то информацию. Эти все данные(пары имя-значение) можно либо хранить в простой модели или взять что-то стороннее посерьезней, например dbsettings.

Для примера я возьму простую модель:

class Entry( models.Model ):
   name = models.CharField( max_length = 50, unique = True )
   value = models.CharField( max_length = 150 )

Здесь и далее буду писать упрощенный код

Всё, данные есть где хранить, но их ещё и нужно удобно вывести в шаблон. Первое что приходит в голову для решения - сделать шаблонный тег. Да, и вправду просто и сердито:

@register.simple_tag
def get_conf( name ):
    return Entry.objects.get( name = name )

И использовать легко, примерно так:

<meta name="keywords" content="{% get_conf "meta_keywords" %}"/>

Но у этого способа по сути одно маленькое положительное качество - в этот тег можно передать переменную, а не жестко закодированную строку("hardcoded" - правильно перевел?:)) с названием. Но ...

Читать далее