В КУРСЕ?

Разбираемся в теме

RSS-агрегатор снова показывает ту же запись: какой признак считать её идентификатором?

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

Название и дата не заменяют устойчивый ключ

В записи RSS может присутствовать поле guid, предназначенное для её идентификации. Оно необязательно, поэтому агрегатор должен учитывать и отсутствие такого значения. Идентификатор следует рассматривать как строку. В зависимости от атрибута isPermaLink он может обозначать постоянную ссылку, но не всякое его значение следует автоматически открывать как адрес. Заголовок менее удобен в роли ключа: его могут исправить, а разные записи способны иметь одинаковое название. Дата также описывает время, а не гарантирует уникальность. В собственной учебной системе договоримся хранить пару: обозначение исходной ленты и её идентификатор записи. Это выбранная политика нашего примера. Она помогает различать происхождение материалов и не смешивать одинаковые значения из разных источников.

Обновление содержания не обязательно создаёт новую запись

Пусть первая загрузка принесла записи с условными ключами один и два. Во второй загрузке снова пришёл ключ два, но его заголовок исправлен, а также появился ключ три. При выбранном правиле в хранилище останутся три записи. У второй можно обновить изменившиеся поля, сохранив связь с прежним ключом. Если сравнивать только заголовки, исправленная версия могла бы ошибочно стать четвёртой записью. Отдельно полезно хранить время получения и исходную дату публикации. Эти значения отвечают на разные вопросы: когда агрегатор увидел материал и когда его датировал источник. Если идентификатора нет, потребуется явно выбранное запасное правило, например использование стабильной ссылки при её наличии. Такое правило имеет ограничения и не должно считаться безошибочным. Для спорных случаев полезно сохранять достаточно исходных сведений, чтобы понять причину решения. Иначе позднее будет трудно отличить настоящий дубль от двух похожих материалов.

Проверяйте повтор и неудачную загрузку отдельно

Повторная обработка одного и того же набора должна давать тот же состав записей в рамках выбранной модели. Это простой способ проверить, что получение ленты не создаёт лишние карточки. Ошибка сети или разбора документа не означает, что все прежние материалы исчезли. Поэтому неудачную загрузку не следует автоматически превращать в очистку хранилища. Состояние получения и состояние сохранённых записей лучше учитывать отдельно. RSS использует XML, а входной документ нужно считать недоверенным. При настройке обработчика ограничивают работу с внешними сущностями и другими возможностями, которые могут обращаться к нежелательным ресурсам. Конкретные настройки зависят от выбранного средства разбора. Проверка идентичности также не подтверждает качество или достоверность содержимого. Агрегатор знает, какую запись он уже видел, но не становится проверяющим все её утверждения. Начинать удобно с маленького вымышленного набора. В нём можно заранее описать ожидаемый результат и проверить повтор, изменение заголовка и появление действительно новой записи.

Попробуйте на практике

Разберите две вымышленные загрузки одной ленты на бумаге.

  1. В первой загрузке создайте записи с ключами один и два. Для каждой запишите заголовок и обозначение источника.
  2. Во второй загрузке повторите ключ два с новым заголовком и добавьте ключ три. Примените правило идентификации по источнику и ключу.
  3. Повторно обработайте второй набор и проверьте, что число сохранённых записей остаётся равным трём.
  4. Добавьте отдельный сценарий ошибки загрузки. Запишите, что прежние записи сохраняются, а ошибка отмечается отдельно; затем обозначьте ограничение запасного правила для записи без идентификатора.

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

Частые вопросы

Можно ли всегда использовать заголовок как уникальный ключ?

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

Если guid отсутствует, запись обязательно некорректна?

Нет. Это необязательное поле. Агрегатору нужно собственное запасное правило и понимание того, в каких случаях оно может ошибаться.

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

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

Зарегистрироваться
← К списку материалов