Архив за [undefined]

Тебе ровно год!

Точнее с момента первого поста прошел ровно год. Да, много чего я успел рассказать на твоих страницах, мой блог, но ещё больше не успел.

Ты изменил мою жизнь. Да, это чистая правда. Ты заставил меня посмотреть на себя под другим углом. Ты помог мне получить бесценный опыт письма и общения. Ты помог мне найти себя в системе координат жизни. И теперь я точно знаю зачем ты есть и для чего. Мы вместе будем продолжать идти вперед и у нас всё получится.

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

Спасибо тебе. Поздравляю тебя. Долгой жизни тебе.

Сливаемся

Беру небольшую передышку в своих изысканиях о композитных полях для большего прилива вдохновения. Подамся-ка я в другую область на время.

Представим себе ситуацию(а лучше вспомним один из прошлых проектов, который вы делали:)), что есть пара приложений от сторонних разработчиков. И это не какие-то совсем простые приложения, а что-то более комплексное. А отличительной чертой их комплексности будет наличие в каждом своей модели профиля. Ведь было такое? Увы, было. Ну и пусть будут, только вот ещё незадача - их поля являются пересекающимися множествами. Ну т.е. и в том и в другом есть, допустим, поле с ссылкой на сайт владельца. И что же делать? Конечно, для облегчения работы интерфейс редактирования информации профиля один для выбранного основного профиля. А объектов профиля закрепленных за пользователем два (а может быть и больше, если проект используем много разных приложений). Надо как-то синхронизировать данные...

Вообще ситуация того, что в каждом мало-мальски большом приложении свой профиль - это как бы уже давно проблема. И тут ничег уже не поможет. Универсальный профиль помещенный в contrib, конечно, может как-то решить её, но не всегда. Да и потом, с профилем разберемся, так что-то другое появится. Надо находить универсальные пути решения.

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

Композиция: ForeignAttributeField

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

С момента прошлого поста я успел значительно улучшить базовый CompositionField и решить несколько концептуальных проблем.

Итак что же новое появилось:

  • Сделал низкоуровневый CF полноценным классом, который теперь удобно сабклассить и добавлять новый функционал
  • Появилось место для интроспекции. Присоединение к хост модели стало более интеллектуальным из-за возможного отложенного присоединения.
  • Чуть-чуть изменился интерфейс - параметр commit теперь может быть задан для конкретного триггера. Это сугубо практическое изменение, которое помогло решить одну проблему с бесконечной рекурсией.
  • По совету Вани Сагалаева добавил генерацию freeze_FOO метода, который включает/выключает обработку сигналов. Полезно когда надо обработать какие-то данные скопом, а потом так же скопом пересчитать денормализованные поля.

Я грозился написать высокоуровневые обертки над CF чтобы облегчить использование и упростить конечный интерфейс. Сегодня я расскажу о первом сабклассе CF: ForeignAttributeField - поле которое отслеживает изменения некого внешнего поля в связанном объекте. Причем, поле может находится на любом уровне вложенности связи, что иногда очень удобно. Как я уже писал в прошлый раз - поля объектов, на которые непосредственно ссылается модель, так денормализовывать смыла мало. Проще использовать select_related. Но если заветный атрибут лежит глубже и для доступа к нему надо приджоинить, допустим, пять таблиц, то тут уже другой расклад и ...

Красивая композиция

Нет, я не про музыку решил написать. А про композицию данный, агрегацию если хотите.

В джанге на данный момент агрегации в ORM нет. Но как известно скоро должна появиться, а значит жизнь в очередной раз станет проще.

Зачем?

Но на много ли? Да, писать запросы с агрегацией станет проще. Но в большинстве случаешь выполнять запрос для сервера легче не станет. Вот ту на помощь приходит техника денормализации.

Денормализация - это добавления избыточности данных для увеличения производительности чтения данный. Обычно чтение данных требуется гораздо чаще чем их запись, а значит на запись в принципе можно потратить чуть больше времени, за-то потом много раз сэкономить на выборке. Агрегацию я привел в качестве, наверно, самого популярного источника данных для денормализации, но ею конечно не ограничивается применение денормализации. Суть в том, что лучше что-то тяжелое посчитать при записи и сохранить, чем каждый раз при чтении пересчитывать заново.

Наверно многие из вас в своих проектах писали код наподобие такого, тем более, если писали "свой блог движок":

class Post(models.Model):
   comment_count = models.PositiveIntegerField(default=0)

class Comment(models.Model):
   post = models.ForeignKey(Post, related_name="comments")

   def save(self):
      super(Comment, self).save()
      self.post.comment_count = self.post.comments.count()

   def delete(self):
      super(Comment, self).delete ...

Слишком много дров точка ком

За проектом StackOverflow я наблюдал уже достаточно давно. Слушал подкасты о процессе разработки и ждал когда же увидит свет этот новый сервис. Гений его авторов позволил сделать грамотный ресурс для поиска ответов на разные программистские вопросы.

Для себя я сразу отметил два тега за которыми можно последить - python и django. Там среди кучи достаточно банальных вопросов попадаются и те, что из разряда - "я бы тоже не прочь почитать ответы". И пока, даже сообщество не до конца сформировалось, всё равно есть что почитать.

Так что всем рекомендую. Тем более, иной раз можно и самим кое-где свою точку зрения выразить. Я надеюсь что социальная часть сервиса себя не дискредитирует и получится действительно интересное сообщество с грамотными участниками.