Как создать большой / занятый канал RSS - PullRequest
1 голос
/ 13 сентября 2008

Я играл с RSS-лентами на этой неделе, и для моего следующего трюка я хочу создать один для нашего внутреннего журнала приложений. У нас есть централизованная таблица базы данных, которую наши многочисленные пакетные и интранет-приложения используют для публикации сообщений журнала. Я хочу создать RSS-ленту из этой таблицы, но я не уверен, как справиться с объемом - в обычный день могут быть сотни записей в день. Исключительный день "сделай, что хочешь бросить" может увидеть несколько тысяч. Есть мысли?

Ответы [ 6 ]

3 голосов
/ 17 сентября 2008

Я бы сделал статический файл (вы можете легко обслуживать тысячи таких), периодически регенерировал Тогда у вас есть гораздо более широкий выбор, потому что он не должен работать меньше секунды, он может работать даже минуты. И пользователи по-прежнему получают идеальную скорость загрузки и разумную скорость обновления.

2 голосов
/ 15 сентября 2008

Если вы создаете систему с уведомлениями, которые нельзя пропустить, то механизм pub-sub (использующий XMPP, один из других протоколов, поддерживаемых ApacheMQ или что-то подобное) будет более подходящим, чем механизм синдикации. Вам нужна некоторая мера связи между системой, которая генерирует уведомления, и теми, которые их используют, чтобы потребители не пропустили уведомления.

(Вы можете сделать это, используя RSS или Atom в качестве транспортного формата, но, вероятно, это не обычный случай использования; вам нужно будет изменить отображаемые уведомления в зависимости от потребителя и того, какие уведомления он уже видел.)

1 голос
/ 07 января 2009

Я бы разделил фиды как можно больше и позволил бы пользователям рекомбинировать их по своему желанию. Если бы я делал это, я бы, вероятно, подумал об использовании Django и инфраструктуры синдикации.

Модели Django могут, вероятно, обрабатывать представление структуры данных таблиц, которые вам интересны.

У вас может быть URL-адрес, который перехватывает все, например: r'/rss/(?(\w*?)/)+' (думаю, это может сработать, но я не могу проверить его сейчас, поэтому он может быть не идеальным).

Таким образом, вы можете использовать URL-адреса, такие как (отредактировано для отмены автоматической ссылки на примеры URL-адресов):

  • http: // feedserver / rss / batch-file-output /
  • http: // feedserver / rss / support-tickets /
  • http: // feedserver / rss / batch-file-output / support-tickets / (оба из первых двух объединены в один)

Тогда в представлении:

def get_batch_file_messages():
    # Grab all the recent batch files messages here.
    # Maybe cache the result and only regenerate every so often.

# Other feed functions here.

feed_mapping = { 'batch-file-output': get_batch_file_messages, }

def rss(request, *args):
    items_to_display = []
    for feed in args:
        items_to_display += feed_mapping[feed]()
    # Processing/returning the feed.

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

0 голосов
/ 15 сентября 2008

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

0 голосов
/ 15 сентября 2008

Хорошо, я решил, как я справлюсь с этим. Я использую поле метки времени для каждого столбца и группировки по дням. Требуется немного SQL-фу, чтобы это произошло, поскольку, конечно, там есть полная временная метка, и мне нужно быть полу-умным в отношении того, как я выбираю сообщение журнала для показа внутри группы, но это не так уж плохо. Кроме того, я создаю его, чтобы вы могли выбрать, какое приложение отслеживать, а затем отображать каждое сообщение (максимум 50) за определенный день.

Это сводит меня к чему-то разумному.

Я все еще надеюсь на хороший ответ на более общий вопрос: «Как вы объединяете много важных сообщений, когда пропущенное сообщение может быть проблемой?»

0 голосов
/ 13 сентября 2008

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

Тем не менее, в подобных системах часто бывает уровень серьезности. У вас может быть параметр строки запроса, который вы добавляете в конец URL, который указывает серьезность. Если установлено значение «DEBUG», вы увидите каждое событие, независимо от того, насколько оно тривиально. Если вы установите значение «FATAL», вы увидите только те события, которые были «System Failure» по величине.

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

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

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