Интернет нового века | Последние записи |

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

2008-11-17T22:23:18Z

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

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

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

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

Теги:
личное о блоге

Сливаемся

2008-10-13T02:29:22Z

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

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

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

Кстати, обсуждения данной темы были как на неформальной встрече джангистов по поводу 1.0 релиза, так и на не менее неформальном минибаре для программистов. В результате всех обсуждений, стало понятно, что решений данной проблемы два - это либо синхронизация пересекающихся полей в моделях, либо какой-то базовый прототип/интерфейс для модели, на который можно рассчитывать и ссылаться в коде.

Сейчас я покажу свой вариант первого решения - синхронизации. В лучших своих традициях - начну с примера.

Итак, есть две модели профиля пользователя в разных приложениях. Вот такие:

class MyProfile(models.Model):
   user_ptr = models.ForeignKey(User, unique=True)
   nickname = models.CharField(max_length=100)
   www = models.URLField()
   birth = models.DateField()

class OtherProfile(models.Model):
   user = models.ForeignKey(User, unique=True)
   nickname = models.CharField(max_length=100)
   website = models.URLField()
   dob = models.DateField()

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

Нам надо чтобы объекты этих моделей, прикрепленные к одному и тому же пользователю, синхронизировались при изменении любых из них. Т.е. нам надо слить изменения одной в другую. Я почему-то решил назвать это, уже преследующим меня, словом - merge. И получился у меня merging framework.

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

import merging

class MyProfileLayer(merging.ModelLayer):
   model = MyProfile
   fields = ["nickname"]
   aliases = {
       "site": "www",
       "day_of_birth": "birth"
   }
   key = 'user_ptr'

class OtherProfileLayer(merging.ModelLayer):
   model = OtherProfile
   fields = ["nickname"]
   aliases = {
       "site": "website",
       "day_of_birth": "dob"
   }
   key = 'user'
   create = True

Тут я указал модель(model) и поля в атрибуте fields, в частности нужно сливать никнеймы. Для полей с разными названиями я указываю алиасы через aliases. Причем, обратите внимания, что алиасы имеют одинаковое название для обеих прослоек. На основе именно этих имен будет происходить синхронизация настоящих полей. Для обеих прослоек я указываю ещё и атрибут - key. На базе него будет происходить выборка связных профилей.

Для второй прослойки я ещё указал create=True, чтобы, если главный профиль(MyProfile) существует, а OtherProfile нет, создавался бы автоматически объект последнего.

Ура, описательную часть закончили, теперь надо запустить механизм отслеживания. Вот так:

merging.track([MyProfileLayer, OtherProfileLayer])

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

Итак, теперь все изменения в указанных полях будут перетекать в связные объекты:

>>> profile = MyProfile.objects.create(user_ptr=user, nickname="test",
...                                    www="http://webnewage.org/", birth="1987-06-25")
...
>>> other = OtherProfile.objects.get(user=user)

>>> profile.__dict__
{'birth': datetime.date(1987, 6, 25),
 'id': 1,
 'nickname': u'test',
 'user_ptr_id': 1,
 'www': u'http://webnewage.org/'}

>>> other.__dict__
{'dob': datetime.date(1987, 6, 25),
 'id': 1,
 'nickname': u'test',
 'user_id': 1,
 'website': u'http://webnewage.org/'}

>>> profile.www = "http://yandex.ru/"
>>> profile.save()

>>> other = OtherProfile.objects.get(pk=other.id)
>>> other.website
u'http://yandex.ru/'

>>> other.nickname = "foobar"
>>> other.save()

>>> profile = MyProfile.objects.get(pk=profile.id)
>>> profile.nickname
u'foobar'

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

Как обычно основные use cases покрыты тестами, так что можете смело пользоваться.

На очереди следующий вызов - фреймворк прототипов. Вперед и с песней!;)

Теги:
django orm python web

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

2008-10-07T01:20:33Z

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

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

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

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

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

Пример с фильмом и режиссером из предыдущего поста перепишу по новому и добавлю ещё одно поле:

class Country(models.Model):
   name = models.CharField(max_length=250)

class Person(models.Model):
   name = models.CharField(max_length=250)
   country = models.ForeignKey(Country)

class Movie(models.Model):
   title = models.CharField(max_length=250)
   director = models.ForeignKey(Person)

   director_name = ForeignAttributeField("director.name")
   director_country = ForeignAttributeField("director.country.name")

Теперь посмотрим как это работает:

>>> country = Country.objects.create(name="USA")
>>> person = Person.objects.create(name="Steven Spielberg", country=country)
>>> movie = Movie.objects.create(title="ET", director=person)

>>> movie.director_name
'Steven Spielberg'

>>> movie.director_country
'USA'

>>> person.name = "Steven Allan Spielberg"
>>> person.save()

>>> movie = Movie.objects.get(pk=movie.id)
>>> movie.director_name
u'Steven Allan Spielberg'

>>> country.name = "United States"
>>> country.save()

>>> movie = Movie.objects.get(pk=movie.id)
>>> movie.director_country
u'United States'

Как видите всё довольно прозрачно и естественно. За это я и боролся. Надо только отметить, что в данном примере я явно каждый раз после изменения связных моделей тяну из базы объект movie, чтобы в нем были уже обновленные данные.

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

Поразило также насколько универсальным и обобщенным оказался CF сам по себе. Поскольку его функциональную часть не пришлось менять практически совсем за исключением выноса параметра commit в объявление триггера. Это связано с тем, что далеко не после всех вызовов обработчиков сигналов можно звать save объекта. Например его нельзя вызывать после pre_save/post_save сигналов того же объекта что и был обновлен, а то получается - бесконечная рекурсия.

Ещё - вся функциональность этого высокоуровнего поля заключается в правильном составлении тригеров и обработчиков событий (на базе интроспекции моделей), которые передаются в "отложенный" конструктор CF. Ничего более. Супер!

Файл с исходниками доступен как и раньше тут. Если вы его посмотрите, то заметите заготовки для ещё двух типов полей: ChildsAggregationField, AttributesAggregationField - но они пока на уровне идеи. Как дойдут руки, то обязательно их реализую. Некие намеки на их использования можно посмотреть в тестах.

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

А вам как? Нравится?

Теги:
django orm python signals snippets денормализация оптимизация

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

2008-09-26T02:18:18Z

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

В джанге на данный момент агрегации в 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()
      self.post.comment_count = self.post.comments.count()
      self.post.save()

Либо добивались подобного функционала с использованием сигналов. Ещё наверно дописывали метод update_что-то там чтобы в случае чего, можно было скопом посчитать денормализованное поле:

class Post(models.Model):
   #...
   def update_comment_count(self);
      self.comment_count = self.comments.count()
      self.save()

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

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

Меня всегда мучал вопрос - можно ли это как-то автоматизировать? Оказывается можно и даже вполне красиво.

Долгий путь

Этим вопросом озадачивался конечно не только я. На прошедшем ДжангоКоне тоже встал этот вопрос и он был помечен как надо подумать.

Также, совсем недавно Эндрю Годвин из джанговского сообщества написал в своем блоге про некий DenormField, который магическим образом кешировал в себе некий атрибут ForeignKey объекта. Т.е. да, в некотором роде это денормализация, но уж больно вырожденная. Ведь это по сути замена select_related. А если учесть что джоин по первичному ключу достаточно дешёвый, то смысла делать такую денормализации мало. Но тем не менее это первый шаг в сторону решения задачи. Вскорости автор данной реализации написал о ней в девелоперсах и получил поддержку со стороны участников. Но всем показалось, что решение достаточно локальное и узкоспециализированное. Да тут и казаться нечему - так и есть. Надо улучшать.

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

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

Как?

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

За базовую систему контроля за состояниями решил выбрать сигналы. Тем более у меня, как я уже понял, некая страсть скрещивать что-то с сигналами в декларативном стиле:) В результате у меня получился CompositionField.

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

Для начал возьмем исходный вариант с постом и комментариями и перепишем его с применением CompositionField:

D = dict

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

class Post(models.Model):
   comment_count=CompositionField(
                native=models.PositiveIntegerField(default=0),
                trigger=D(
                        on=(signals.post_save, signals.post_delete),
                        do=lambda post, comment, signal: post.comments.count(),
                        sender_model=Comment,
                        field_holder_getter=lambda comment: comment.post,
                    ),
            )

Получилось немного громоздко, да? Но что мне нравится, даже не смотря на объем, это декларативность, которой удалось добиться. Теперь давайте разберемся, что же здесь происходит.

CompostionField на самом деле не класс, а функция, которая возвращает специально обработанный объект поля в native, принимаемый в качестве параметра. Как легко догадаться, native это непосредственно поле, которое будет создано и куда будет записан некий композиционный результат. Дальше самое интересное - мы описаваем тригер, который по возникновению неких сигналов будет производить операцию и записывать значение в поле. on список сигналов для отслеживания. В данном случае мы будет отслеживать сохранение и удаление объекта. Но в принципе сигналов может быть и больше, либо всего один. do - как раз это та функция, которая будет вызвана при поступлении сигнала. Она то и производит операцию подсчета комментариев. Принимает три параметра, которые говорят сами за себя. sender_model - модель которая должна отослать сигнал. Все логично, у нас это Comment. Ну и последний параметр - field_holder_getter это функция, которая по объекту комментария должна возвращать соответствующий пост.

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

Да, ещё бесплатный бонус - мы получаем автоматически сгенерированный update_comment_count, который может быть использован в крайнем случае.

Ну как вам? Нравится? Но это ещё не всё. Система намного гибче чем я показал в этом примера. Давайте посмотрим ещё одну ситуацию.

Допустим, что есть некоторое событие Event и есть несколько пришедших на него - Visit. И мы хотим денормализовать количество пришедших. В принципе по структуре ситуация идентична случаю с постом и комментариями, но на ней я покажу другие возможности CompositionFIeld.

D = dict

class Visit(models.Model):
   event = models.ForeignKey("Event")

class Event(models.Model):
   visit_count = CompositionField(
                native=models.PositiveIntegerField(default=0),
                trigger=[
                    D(
                        on=signals.post_save,
                        do=lambda event, visit, signal: event.visit_count + 1
                    ),
                    D(
                        on=signals.post_delete,
                        do=lambda event, visit, signal: event.visit_count - 1
                    )
                ],
                commons=D(
                    sender_model="app.Visit",
                    field_holder_getter=lambda visit: visit.event,
                ),
                commit=True,
                update_method=D(
                    do=0,
                    initial=0,
                    queryset=lambda event: event.visit_set.all(),
                    name="sync_visit_count"
                )
            )

Кода стало ещё больше, но он за-то покажет другие интересные моменты. Как вы заметили, если раньше был один тригер, то теперь их два - т.е. тригеров может быть несколько. Теперь каждый из них повешен на свой сигнал и считают они комментарии на базе уже имеющегося значения счетчика. Хочу отметить, что лучше так не делать, поскольку если вы работает в транзакции, то можете получить неожиданные результаты по завершению:) Но в качестве демонстарции, это не особо важно. Далее, поскольку два тригера похожи, то общие их свойства выделены в отдельный параметр commons, который создан для упрощения объявления родственных тригеров. commit=True - говорит о том, что объект после применения обработчика нужно сохранить. Кстати, тут это просто для наглядности, поскольку это поведение по-умолчанию.

Ну и, наконец, параметр update_method, о котором расскажу более подробно. Он позволяет кастомизировать генерацию стандартного метода обновления. Т.к. обновление счетчика у нас инкрементальное, то во-первых перед выполнением метода, счетчик надо обнулить(initial=0). Также нужно знать какой тригер применять. В данном случае счетчик мы будем каждый раз увеличивать, то я выбрал первый тригер с индексом 0 (do=0).

queryset это очень интересный параметр. Поскольку тут выполнение действия идет не по сигналу, а по факту вызова метода, то для правильной работы имеющегося тригера, нужно указать множество объктов для его применения. В этом случае множество посетителей заданного события. Ну и name это переопределение стандартно сгенерированного update_FOO имени метода на какое-то своё.

Классно, да? Но и это не всё. Рассмотрим ещё одну ситуацию, похожую на ту которую предложил автор DenormField. Есть кинофильм и есть его режиссер. Режиссер может быть автором нескольких фильмов, поэтому модель такая:

class Person(models.Model):
   name = models.CharField(max_length=250)

class Movie(models.Model):
   title = models.CharField(max_length=250)
   director = models.ForeignKey(Person)

   headline=CompositionField(
        native=models.CharField(max_length=250),
        trigger=D(
             sender_model=Person,
             field_holder_getter=lambda director: director.movie_set.all(),
             do=lambda movie, _, signal: "%s, by %s" % (movie.title, movie.director.name)
          )
    )

Тут уже меньше кода. Нового тут объяснять особо нечего. Это простой пример другой ситуации. Подсчет некого хедлайна получился достаточно простой.

Ну вот пожалуй пока всё.

Что дальше?

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

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

Путь упрощения - написание более высокоуровневых шорткатов, которые покрывали бы самые распространенные варианты использования, т.е. что-то типа CountField, RelatedAttrField и т.п. Но это уже другая история.

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

Вот, теперь я замолкаю и даю вам возможность ещё раз посмотреть код, может быть залезть в реализацию и понять как бы вы могли применять подобное решение. Предлагайте какие-то новые ситуации, будем пробовать положить их на такую концепцию.

Теги:
caching db django orm python signals snippets web денормализация

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

2008-09-23T07:17:07Z

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

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

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

Теги:
django python snippets web ссылки

Рождение Django 1.0

2008-09-04T08:32:06Z

Ну вот. Даже как-то грустно. То чего все мы так долго ждали наконец свершилось. Джанга родилась в своем релизном варианте с гордым "1.0" на ярлыке.

Почему грустно? Да потому, что тот темп, с которым менялась джанга последний год(с лишним), приучил нас быть всегда в тонусе, следить за изменениями, подстраиваться под них и как-то менять своё видение этого чудесного фреймворка. А что теперь? Мне кажется что темп упадет, а значит и драйв обитания на trunk будет не такой как раньше.

Ну ладно с ним с драйвом, будем искать в других областях. Важно то что наконец джанга должна приобрести общепризнанный статус production/enterprise-ready и пойти в массы с ещё более быстрыми темпами. Компании (конечно в большей степени управленцы в них), которые раньше на этапе выбора платформы и инструмента воротили нос от продукта, который был, как им казалось, не готов для боевого применения, сейчас начнут пересматривать свои воззрения, и уже для новых проектов боле пристально смотреть на джагу как на реального кандидата в освоении и применении. Я на это надеюсь по крайней мере. Пусть для многих смелых и разумных, уже давно джанга вполне была готовой к бою, но всё равно оставались сомневающиеся.

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

Кстати, то что была организована Django Software Foundation, тоже придает солидности и добавляет козырей в колоду нашего любимого фреймворка.

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

Главное, чтобы после вселенской гулянки, корные разработчики продолжали привносить новые идеи и концепции для улучшения существующего положения вещей внутри фреймворка. А мы в свою очередь будем продолжать их осваивать и использовать в своих разработках, пусть с меньшей скоростью чем раньше. Но может быть это и не плохо? А может вообще всё будет по другому? Посмотрим.

Огромный шаг в завоевании умов и сердец веб-разработчиков сделан, кто раньше ещё размышлял "быть или не быть", теперь с большей долей вероятности скажут - "быть"!

Что же, живем и работаем дальше, но уже с чуть другим чувством. Да, и приходим обязательно на локальную гулянку в честь этого события!

PS: Интересно, а я один был озабочен вопросом - кто быстрее: джанга или гугл хром:)

Теги:
django python web

Горизонтально, вертикально и вперемешку

2008-08-19T14:20:16Z

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

Горизонтальная модель показалась мне более читаемой. Т.е. она более похожа на табличные выборки из баз данных. И как не странно, её проще парсить и обрабатывать. Ставка на атрибуты, идентификаторы которых уникальны в приделах одного элемента, себя оправдывает и не порождает излишеств.

Вертикальная модель подразумевает активное использование дочерних элементов. Из-за этого документ получается более "толстым". Причем зачастую. использование дочерних элементов не очень оправдано. Они не используются как контейнеры для других элементов и даже CDATA там не хранится. А читать труднее. Хотя и появляется некая древовидная структура, но достаточно вырожденная и почти плоская. Ну и много "паразитной" разметки получается как следствие.

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

Кстати, достаточно просто можно определить насколько XML модель соответствует внутренней модели данных в базе и насколько данные трансформировались и адаптировались для XML'ного представления. Когда вы работаете со структурой, которая полностью соответствует классической нормализованной схеме базы данных, то сразу понимаете, что XML является практически "снимком" данных этой базы. Да, генерация заметно упрощается, но это ставит крест на читаемости и удобстве обработки принимающей стороны. Разгребать ворохи "ссылок" и странных идентификаторов - каторга.

Под чтением я понимаю, именно чтение человеком, т.е. мной. Я приверженец того мнения, что XML не для чтения и написания самим человеком, тем более, когда многие об удобстве забывают и генерируют ужасные схемы. Это машинный формат и то что он текстовый это всего лишь деталь реализации и одна из особенностей, а не параметр, который сразу записывает его в легко-человеком-воспринимаемые форматы. Воспринимать вертикальный и сильно "нормализованный" документ сложно. Конечно можно привыкнуть, но не стоит. По крайней мере один раз прочесть документ надо - для того чтобы написать конвертер в свои бизнес объекты. А потом забыть и доверить генерацию/потребление на откуп программе. Отсюда вывод: не надо делать, например, конфигурационные файлы на база XML и уже тем более не стоит делать на его основе мало-мальски сложные DSL. Пусть на XML'е разговаривают программы. Но это мнение не все, увы, разделяют. Ant тому пример - популярен бешено, хоть в определенной среде, где XML культ.

XML вызывает у меня радугу эмоций. Это не плохо на самом то деле...

Теги:
db web xml

А вы поймали новые сигналы?

2008-08-07T15:30:49Z

Вчера джанга сделал ещё один существенный шаг на пути к долгожданному релизу 1.0. На этот раз посчастливилось обновиться инфраструктуре сигналов. Основное и главное отличие новой подсистемы сигналов - это почти двукратное увеличение производительности.

Исторически сигналы в джанге были сделаны на базе пакета pyDispatcher. который почти без изменений был скопирован в django.dispatch. Со временем выяснилось, что он избыточен и медленен.

Сигналы практически везде пронизывают код джанги. Повесить обработчик можно и на изменение объекта, и на начало и конец обработчик запроса и рендеринг шаблона и много чего ещё. Причем они не только предоставляют некий интерфейс взаимодействия с внешним миром, но и активно применяются внутри самой джанги. Например, удаление загруженных файлов вслед за объектами и закрытие соединения с базой при завершении обработки запроса(!).

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

Возможности погонять тесты у меня нет, так что поверим разработчикам на слово. Лучше копнем поглубже в суть.

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

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

Первым делом объявим сигнал:

from django.dispatch import Signal

dinner_is_served = Signal()

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

Как мы знаем, сигналы обычно обозначают наступление какого-либо события. События происходят в каком-то окружении, а следовательно вместе с сигналами распространяется некая мета информация, описывающая как раз контекст его возникновения. Теперь у разработчика есть явная возможность помимо стандартного sender описать ещё дополнительные параметры, с которыми сигнал должен посылаться. Выглядит это так:

dinner_is_served = Signal(providing_args=["courses", "dessert"])

Т.е. по логике при посылке данного сигналы должна быть указано подмножество этих аргументов. Но это нигде не проверяется и получается что это всего лишь такой вариант самодокументирования:) Допилят позже надо полагать.

Ну всё, сигнал объявили и надо его послать всем желающим:

dinner_is_served.send(sender="Barrymore", courses=["soup", "oatmeal porridge"], dessert="pudding")

Добавить то желающих тоже просто:

def sherlock_holmes(sender, courses, dessert, **kwargs):
   pass

dinner_is_served.connect(sherlock_holmes)

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

Итак, подведем итог. Для того чтобы максимально просто и безболезненно заставить работать старый код после очередного svn up джанги, надо явным образом создавать объект сигнала. Всё остальное должно работать. Если конечно вы не использовали какие-то более изощренные способы работы с сигналами.

Избавиться совсем от наследия pyDispatcher не получилось. Был оставлен модуль saferef.py в котором реализована "слабая ссылка"(weak reference) и по умолчанию обработчики, присоединяемые к сигналу, таковыми являются. Но это поведение можно изменить, добавив при присоединении хендлера параметр weak=False.

Кстати, косвенно с этим связанна ещё одна интересная особенность подсистемы сигналов.

Представим, что у нас есть код:

def some_func(param):
   def handler(*args, **kwargs):
      pass

   some_signal.connect(handler)

И потом вы эту some_func зовете несколько раз. И когда сигнал сработает, что должно произойти? Правильно. Ничего. Хендлер не сработает потому что из-за "слабой" ссылки GC его убьет, а то что мы его зарегистрировали его не волнует. Поэтому добавляем weak=False:

some_signal.connect(handler, weak=False)

А что теперь будет? Ага, обработчик сработает несколько раз, точнее столько раз сколько мы вызвали функцию some_func в рамках жизни данного процесса. Для того чтобы избежать повторного добавления обработчика, есть очень полезный параметр dispatch_uid, который, если присутствует, должен быть уникальным идентификатором данного хендлера - строка или что угодно hashable. Вот так например:

some_signal.connect(handler, weak=False, dispatch_uid="my_useful_unique_handler")

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

Шаг очередной джанга сделала, мы его обсудили и ждем следующего. А это "file storage" между прочим - тоже веха!

Обновление:

Произошло одно маленькое изменение - хендлеры сигналов должны обязательно принимать **kwargs, а то получите эксепшен при попытке его присоединить

Теги:
django python signals web

Спринтеры в Яндексе

2008-07-22T20:11:21Z

Нет, конечно не Майкл Джонсон и Ко, а мы - отчаянные джангисты. Прошло уже больше недели, а я вот только сейчас могу рассказать, а главное даже чуть-чуть показать как это было.

Технические итоги спринта подвел очень лаконично Ваня Сагалаев, я же больше расскажу чуть про процесс.

И так, в субботу 12 июля в одном из московских офисов Яндекса, собрались люди чтобы подправить джангу. Собирались долго, поскольку для многих оказалось неожиданностью, что привычные шатлы от метро по выходным не ходят и надо добираться пешком. Сюрпризом это стало и для некоторых сотрудников самого Яндекса, к слову, которых набралось целых 3 человека.

Принимал нас Яндекс в большой столовой, с заранее приготовленными для нас вкусностями.

Когда уже почти все собрались и немного познакомились, Ваня взял вступительное слово, рассказал немного про процесс спринтования и все неспеша полезли в джанговский трак чтобы захватить себе тикет получше. Те кто просмотрел их список заранее, сразу выбрали что-то себе. Откровенно говоря, интересных задачек было мало. Они либо слишком нудные, либо какие-то очень заумные и специфичные.

Кстати, была группа, которая занималась не доводкой NFA, а реализацией улучшенного бекэнда для Oracle, как потом оказалось, из очень серьезной конторы:) Но об этом попозже.

Так, я оказался в числе тех самых, подготовленных, и выбрал очень простой себе тикет, т.к. на что-то более серьезное не хватило бы времени. Суть его заключалась в том, чтобы избавится от ненужных проверок на "залогиненность" пользователя. Я быстро набросал патч #6991, который потом всё равно Ване пришлось подправлять, залил его в трак и уж было собрался уходит на дерби. Как вспомнил, что у меня есть телефон-фотоаппарат. И устроил маленькую фотоохоту на спринтеров, которые были погружены в процесс. Вот что получилось:

Было немного грустно, что все вот так сидят и мало кто представляет, откуда кто приехал и чем занимается. И тут я вспомнил что у меня телефон ещё и видеокамера!:) Быстро сообразив как это использовать, я попросил всех немного рассказать и себе и о своем занятии. Получился такой не плохой ролик с представлением участников:

Django-sprint at Yandex 12 July 2008 from Alex Koshelev on Vimeo.

Потом я быстро собрал свой ноутбук и отправился в дорогу. Но это уже совсем другая история. И в противовес этой - очень грустная.

В итоге, я был очень доволен что всё таки приехал на спринт и познакомился с интересными людьми. Было немного жаль, что не досидел до конца, потому что там было много интересного и пицца:)

Хочу ещё!

Теги:
django opensource web личное яндекс