Прочтенные сообщения

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

Идея

Весь вопрос, в общем-то, в архитектуре. Самое очевидное решение — M-M связь между пользователями и статьями типа такого:

class Profile(Model):
  # ...
  read_articles = ManyToManyField(Article)

Проблема же его в том, что оно получается очень накладным. Если форум читают 100 пользователей и в день появляется по 10 статей, то за год в этой табличке накопится 100 * 10 * 365 = 365 000 записей. А еще эта табличка будет все время join'иться со статьями, и хотя я понимаю, что современные СУБД все таки не составляют реально в памяти больше миллиарда записей, все равно это уже немало. Но самое плохое, что эта нагрузка будет всегда только расти, и это будет чувствоваться на всех SELECT'ах форумных страниц.

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

[(1, 20), (25, 30), (32, 100)]

Каждый диапазон получается из идущих подряд прочтенных ID. Заново прочтенные статьи аккуратно вливаются в диапазоны. Если юзер прочитал статью с ID=31, то его список диапазонов станет таким:

[(1, 20), (25, 100)]

Если юзер читает форум регулярно и целиком, то объем данных не будет расти вообще, это будет один диапазон (1, N). В самом худшем случае, когда на форум придет какой-нибудь придурок любознательный герой и начнет читать статьи точно через одну, то объем данных будет расти линейно. Но я надеюсь, что таких будет мало, и общей картины они не изменят.

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

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

Реализация хранения

Первый вопрос — как эти диапазоны хранить. В самом Питоне это удобнее всего представить именно как список tuple'ов (как я выше и рисовал). В Django же никакого встроенного поля для такой вещи нет. Поэтому я придумал просто pickle'ить их в строку и хранить в TextField.

В Питоне словом "pickle" называется сериализация — превращение объектов в некое строковое представление. Для него есть стандартный модуль pickle

Сам процесс сериализации и десериализации оформил в отдельные методы, а их привязал к свойству:

class Profile(models.Model):
  # ...
  read_articles = models.TextField()

  def _get_read_ranges(self):
    from cPickle import loads
    if not self.read_articles:
      return [(0, 0)]
    return loads(self.read_articles)

  def _set_read_ranges(self, ranges):
    from cPickle import dumps
    self.read_articles = dumps(ranges)

  read_ranges = property(_get_read_ranges, _set_read_ranges)

# чтение:
# profile.read_ranges  --> выдает [(,)..(,)]
# запись:
# profile.read_ranges = [(,)..(,)]

У профиля также есть два публичных метода для собственно работы со всем хозяйством

• set_news: проставляет признаки наличия новых статей переданным топикам или форумам
• add_read_articles: вливает новые прочитанные статьи в имеющиеся диапазоны

Назначение второй должно быть понятно, а вот первая появилась не сразу. Сначала вместо нее была функция, которая получала номер топика и отвечала, есть ли в нем статьи, которые юзер еще не видел. Это оказалось непрактичным, потому что на странице с 20 топиками функция вызывалась для каждого, и для каждого делала отдельный запрос с IDшками его статей. Это было обречено тормозить. На странице с форумами пришлось бы для каждого форума вытягивать ID всех его статей — то есть в итоге вообще всех статей. Это было обречено тормозить еще больше...

Поэтому появилась хитрая функция set_news, которая принимает набор топиков (или форумов), берет их ID и составлят один SQL-запрос статей, принадлежащих топикам (или форумам). В тот же запрос в качестве ограничения запихиваются прочитанные диапазоны пользователя. В итоге, БД делает все работу по выфильтровыванию нечитанных статей за один запрос. Этот запрос еще и группируется по переданному списку топиков (или форумов), и на выходе в итоге получается табличка вида "ID топика (форума) — количество нечитанных статей". Последнее, что функция делает — это проставляет эти количества прямо тем объектам, которые были в нее переданы.

Тяжело? :-). Может быть в виде кода будет понятней (сокращенный вариант без проверок и только для топиков):

def set_news(self, topics):

  # полчить список ID
  ids = [str(t.id) for t in topics]

  # условие "только принадлежащие переданным топикам"
  condition = 'topic_id in (%s)' % ','.join(ids)

  # составляем ограничение по диапазонам
  ranges = ''
  for range in self.read_ranges:
    if ranges:
      ranges += ' or '
    # range (N, M) очень удобно годится для подстановки в строку
    ranges += 'a.id between %s and %s' % range

  # условие с диапазонами целиком отрицатется, нам нужны *не*прочитанные
  condition += ' and not (%s)' % ranges

  # финальный запрос
  query = 'select topic_id, count(1) as c from cicero_article a where %s group by 1' % condition

  # выполняется вручную, используя текущее соединение с БД из Django
  from django.db import connection
  cursor = connection.cursor()
  cursor.execute(query)

  # получаемые пары (topic_id, count) составляются в dict для поиска
  counts = dict(cursor.fetchall())

  # проставляем всем топикам атрибут new с количеством нечитанных,
  # используем 0 для топиков, которые не попали в запрос (прочитаны целиком)
  for topic in topics:
    topic.new = counts.get(topic.id, 0)

Вообще, если не лезть в подробности, то с фильтрацией по диапазонам все более-менее понятно: SQL'ная операция "between" подходит для них как нельзя лучше. А вот слияние диапазонов — та еще магия. Пойду, чайку налью, подумаю, насколько подробно про них писать...

Сама функция довольно короткая, получает articles — queryset со статьями, которые надо "прочитать". Это могут быть topic.article_set.all(), Article.objects.filter(topic_forum=forum) и Article.objects.all() для отметки топика, всего форума или вообще всего соответственно.

def add_read_articles(self, articles):

  # составляется условие по прочитанным диапазонам
  from django.db.models import Q
  query = Q()
  for range in self.read_ranges:
    query = query | Q(id__range=range)

  # из переданных статей исключаются уже прочтенные, 
  # выбираются их id
  ids = [a['id'] for a in articles.exclude(query).values('id')]

  from cicero.utils.ranges import compile_ranges, merge_range
  ranges = self.read_ranges

  # compile_ranges из переданных id составляет диапазоны, 
  # проверяя идущие подряд
  for range in compile_ranges(ids):
    # merge_ranges умно вливает каждый диапазон 
    # в результирующий набор
    ranges = merge_range(range, ranges)
  self.read_ranges = ranges

Те, кто действительно читает весь этот код, могут заметить, что здесь условие, исключающее диапазоны, составляется джанговским API, а в предыдущей функции составлялось строчками врчуную:

query = query | Q(id__range=range)

# vs.

ranges += ' or a.id between %s and %s' % range

Единственная тому причина в том, что первый запрос нужно было делать с "GROUP BY", которого Django по-нормальному не умеет. Обидно...

Вспомогательные функции "compile_ranges" и "merge_range" описывать не буду. Это довольно нудные циклы с проверками, кому интересно, посмотрите в исходниках в utils/ranges.py. Заодно поругайте, потому что алгоритмизация таких вещей, наверное, не самая сильная моя сторона :-)

Реализация расцветки в шаблонах

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

<ol>
{% for topic in object_list %}
  <li {% if topic.new %}class="new"{% endif %}> (ссылка на топик)
{% endfor %}
</ol>

topic.new, содержащий количество непрочитанных как раз будет в if'е отзываться как нужно.

Интересно только, где эти "new" им проставлять. Другими словами, где вызывать profile.set_news(object_list). Правильный ответ — view. Но только не потому, что это некая "бизнес-логика". Причина чисто практическая: в Django именно во view сходятся вместе понятия "Модель" и "пользователь веб-запроса". Поэтому именно здесь логично их друг с другом связывать.

Но вот проблема:

def forum(request, slug, **kwargs):
  # ...
  kwargs['queryset'] = forum.topic_set.all()
  return object_list(request, **kwargs)

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

Здесь я с чисто практическими целями слегка поломал идеологию и Django, и заодно всего MVC :-). Я сделал шаблонный тег, который дизайнер шаблона должен будет вызывать перед выводом списка:

<ol>

{% setnews object_list %}

{% for topic in object_list %}
  <li {% if topic.new %}class="new"{% endif %}> (ссылка на топик)
{% endfor %}
</ol>

Сам тег тупой: он просто вызывает set_news текущего юзера.

Это, конечно, дико некрасиво, потому что заставляет дизайнера думать о каких-то деталях реализации, которые не имеют никакого отношения к отображению. Но это а) работает б) кажется мне легче, чем альтернативы, а именно — отказаться от использования object_list и сделать паджинацию вручную во view. Другими словами, это еще один случай, где мне кажется, что "practicality beats purity".