В рамках исследования нам нужно разработать некоторые структуры данных, а также предоставить их реализации. Далее описаны требуемые структуры.
Структура, отвечающая за управление нашими индексами.
IndexManager(Path storeDirectory, Path srcDirectory)
Создает IndexManager, сообщая директорию в которой индексы могут создавать свои файлы для хранения данных на диске, а также директорию в которой хранятся исходники кода и гит-дерево.
void addIndex(String name)
Добавляет индекс, позволяет далее работать с ним. Вероятно должно быть создано семейства таких для создания различных имплементаций кэшей, например addTrigramIndex(), в том числе и метод, позволяющий добавлять, кастомные индексы пользователя (разработчика IDE), их точная структура определится позже при проектировании архитектуры.
O(log(количество_индексов)) или O(1)
Index getIndex(String name)
Возвращает добавленный ранее индекс. Возможно создание семейства таких для создания различных имплементаций кэшей, например add getTrigramIndex.
O(log(количество_индексов)) или O(1)
void deleteIndex(String name)
Удаляет индекс, освобождает занятую им память.
O(log(количество_индексов)) или O(1)
На данный момент абстрактная структура, отвечающая за представление указателя на место в файле.
На данный момент абстрактная структура, отвечающая за представление версии персистентого индекса. Под версией может иметься в виду, как LocalHistory, так и коммит.
Интерфейс, отвечающий за методы непосредственного взаимодействия с индексами. Во всех методах к ассимптотике может добавляться некоторое время на работу с памятью. Мы предполагаем, что структуры для методов, вызываемых часто, будут храниться преимущественно в памяти и накладные расходы для них будут минимальны.
void addString(FilePointer place, String addedString)
Метод-обработчик добавления в некоторый файл с некоторой позиции (описывается place) некоторой строки (addedString).
O(addedString.size())
void deleteString(FilePointer place, long length)
Метод-обработчик удаления из некоторого файла с некоторой позиции (описывается place) некоторого количества символов (length).
O(length)
Value getValue(Key key, Revision revision)
Запрашивает из индекса значение из некоторой версии (по умолчанию из текущей рабочей копии).
Revision getCurrentRevision()
Возвращает текущую ревизию текущей рабочей копии.
O(1)
List<Revision> getAllRevisions()
Возвращает все ревизии, для которых подсчитан данный индекс. Возможно мы будем сохранять не список ревизий, а некое дерево, хранящее их, но это определиться на этапе дизайна.
O(1)
void checkout(Revision revision)
Изменяет текущую рабочую копию индекса (то есть ту, на которой будут базироваться последующие изменения) на другую.
O(log(index_size))
Одна из имплементаций интерфейса Index, предназначенная для хранения индекса триграм для последующей реализации полнотекстового поиска в текущей рабочей копии и по всей истории.
List<Revision> getHistoryValue(Trigram key)
Возвращает список всех версий, в которых встречалась данная триграма. Аналогично с getAllRevisions вероятно будет возвращать не лист, а некоторое дерево.
O(Revisions * log(all_bytes_in_indexed_files))
Пользователь создает IndexManager, далее пишет некоторую имплементацию индекса или использует одну из существующих, предоставляет индексу произошедшие изменения в файле. Это позволяет ему совершать запросы к индексу, получая как информацию о текущей копии, так и о любой из проиндексированных версий.
В рамках этого направления нам нужно предоставить первую фичу с разработанными индексами:
- Полнотекстовый поиск по текущей рабочей копии, O(?)
- Полнотекстовый поиск по всей истории коммитов, O(?)
Нам нужно написать плагин для VSC, запускающий наш сервис, а также отправляющий на него запросы о действиях пользователя и получающий ответ (например, результат полнотекстового поиска). Плагин вполне может несколько подтормаживать в силу того, что предназначен для демонстрации работоспособности Java-библиотеки, а не для продакшен-использования.