liuch/psi_new_history.md

## psi_new_history.md

      
    Raw
  

              psi_new_history.md
            
          
    Обсуждение функциональности хранения и отображения истории для Psi+

Функциональность затрагивающая хранилище (касается только SQL версии хранилища).


Хранение истории переписки в привате конференций. Реализовано. По умолчанию отключено, включать тут: options.history.store-muc-private
Хранение логов самой конференции, опционально. А надо ли?
Раздельное хранение истории по аккаунтам. Добавить таблицу accounts. Реализовано.
Значение, указывающее длительность хранения истории в разрезе по аккаунтам и отдельным контактам. В том числе нежелание хранить историю. Поле типа int в таблицах accounts и contacts. Соответствующие поля уже имеются в структуре БД, пока не используются.
Служебная таблица с полями ключ и значение что бы хранить специфичную для хранилища информацию и настройки. Например версию структуры БД. Реализовано, см. таблицу SYSTEM.
Хранить ресурс с которого пришло сообщение. Реализовано.

Функциональность затрагивающая GUI и возможно затрагивающая API запросов к хранилищу.


Избавится от кнопок в нижней части диалога просмотра истории (Earliest, Previous и т.д.). Переделать на динамическую подгрузку истории по требованию.
Загрузка последних нескольких сообщений из истории в окно чата и окно привата конференции. Пока реализовано только для невебкит версии. По умолчанию подгружаются 5 последних сообщений. Меняется тут: options.ui.chat.history.preload-history-size
Просмотр истории не только по выбранному контакту но и по всем контактам и/или всем аккаунтам. В том числе поиск. Несложно реализовать только для sql версии. Реализовано.
Учесть возможность получения и просмотра истории из внешнего хранилища, например XEP-0136.

Разное


Вынести все сохранение истории в отдельные модули, с возможностью получения списка реализованной функциональности.
Реализовать работу с любым типом хранилища отдельным потоком.
Желательно утрясти API доступа к хранилищу истории, выделить оптимизации касающиеся хранения истории в файлах и вынести отдельным патчем. Сейчас в патче есть изменения «файловой» истории касающиеся не только API.
Учесть возможность записи истории в несколько разных хранилищ. Например в файлы со старым форматом и в новый формат. Сейчас именно так пишется, но цель и реализация другие.

Структура БД

Таблица system

Таблица предназначена для хранения специфичной для хранилища информации и настроек. Обращение к этой таблице будет минимизировано. Изначально, при создании хранилища, в этой таблице будет одна запись - версия структуры БД.
CREATE TABLE `system` (
  `key` TEXT,
  `value` TEXT
  );
INSERT INTO `system` (`key`, `value`) VALUES ("version", "1");


key (строка) - ключ, имя параметра.
value (строка) - значение параметра.

Таблица accounts

Список аккаутнов, для которых имеется история сообщений.
CREATE TABLE `accounts` (
  `id` TEXT,
  `lifetime` INTEGER
  );


id (целое) - уникальный идентификатор аккаунта, то же что и в accounts.xml. Позволяет идентифицировать запись для различных операций.
lifetime (целое) - максимальное количество дней для хранения истории. -1 Хранить бесконечно, 0 - не хранить, lifetame > 0 - хранить указанное количество дней.

Таблица contacts

Фактически, список контактов для которых есть сохраненные события.
CREATE TABLE `contacts` (
  `id` INTEGER NOT NULL PRIMARY KEY ASC,
  `acc_id` TEXT,
  `type` INTEGER,
  `jid` TEXT,
  `lifetime` INTEGER
  );


id (целое) - уникальный идентификатор записи. Позволяет идентифицировать запись для различных операций. Так же необходима для связи с таблицей events.
acc_id (строка) - id аккаунта.
type (целое) - Тип контакта. Contact = 1, GroupChatContact = 2.
jid (строка) - JID контакта без ресурса. Для записи привата конференции записывается с ресурсом (ником).
lifetime (целое) - максимальное количество дней для хранения истории. Имеет приоритет над значением, указанным в accounts.

Таблица events

Основная таблица для хранения тела события. Это могут быть сообщения, чат, запросы авторизации, их подтверждение и т.п.
CREATE TABLE `events` (
  `id` INTEGER NOT NULL PRIMARY KEY ASC AUTOINCREMENT,
  `contact_id` INTEGER NOT NULL REFERENCES `contacts`(`id`) ON DELETE CASCADE,
  `resource` TEXT,
  `date` TEXT,
  `type` INTEGER,
  `direction` INTEGER,
  `subject` TEXT,
  `m_text` TEXT,
  `lang` TEXT,
  `extra_data` TEXT
  );


id (целое) - уникальный идентификатор записи. Позволяет идентифицировать запись для различных операций. Так же необходима для связи с таблицей urls.
contact_id (целое) - для связи с таблицей contacts.
resource (строка) - ресурс контакта, с которого или на который отправлено сохраняемое событие.
date (строка) - дата и время события. Строковое значение используется из-за ограничений в SQLite.
type (целое) - тип сохраненного события (chat, error, headline, subscribe и т.п.). Да, отображается не все из того что сохраняется. Значение и наличие этого поля обусловлено реализацией в "старой" версии хранения истории.
direction (целое) - нам событие или от нас. Наше - 1, Нам - 2.
subject (текст) - subject сообщения
m_text (текст) - текст сообщения
lang (текст) - lang сообщения
extra_data (текст) - дополнительные данные, связанные с событием в формате json. Например в этом поле хранятся урлы, прекрепленные к сообщению (XEP-0066).

В SQLite версии хранилища сохраняется столько же данных сколько в хранилище на файлах. Кроме хранения приватов конференций и списка ссылок в сообщении (в старой реализации сохраняется только первая ссылка, остальные отбрасываются).