Сохранение (кэширование) результатов проверок по репозиторию (репозиториям)

[zmm]

Есть идея сохранять на файлы / в БД статус попарных проверок с привязкой к коммитам / датам измененений, чтобы не делать в повторных запусках лишние проверки (не сравнивать файлы, которые мы сравнили ранее, а новых изменений в них нет)

[zmm]

Какой хочется видеть эту фичу - максимальная комплектация:

• в процессе проверки набора репозиториев / диапазона веток / файлов приложение должно кэшировать (== сохранять в БД )
  -- построенные синтаксические деревья проверяемых файлов, помечая их составным ключом: имя файла, путь, название репо, дата изменения файла.
  -- сохраненные результаты сравнения пар, идентификатор - два составных ключа по принципу из пункта выше
• если производим повторную проверку, то
  -- в начале запрашиваем значения плагиата для пар в кэше,
  -- затем (если пары нет) построенные деревья в кэше.
  -- если дата изменения файлов больше чем дата из кэша, то после выполнения сравнения запись в кэше обновляем

Минимальная комплектация - все что выше, но кэшируем только результаты сравнений.

Что использовать в качестве БД - MongoDB, деревья сохраняем в виде JSON.
Добавляем контейнер с БД и создаем docker-compose, каталог с данными БД превращаем в volume. Тогда все решение не будет терять данные при перезапуске.

[Artanias]

Добавить сверку хэша для файлов/метаданных (ASTFeatures), собранных с файла (проверяем сходство с файлом повторно только если его хэш сумма изменилась по отношению к прошлой).
Получение ASTFeatures судя по экспериментам в https://github.com/OSLL/code-plagiarism/blob/main/docs/notebooks/time_survey.py.ipynb занимает (до 0.14с для работ длиной 1000 строк) сравнительно мало времени, относительно проверок (для структурной до 90с при сравнении работы длиной в 500 строк с работой в 1000 строк), но, например, для внешних источников это дополнительный запрос.
Также относительно быстрых метрик при сравнее 500 строчной работы с 1000 строчной разница в 100 раз, 0.14с для получения метаданных и 0.0014с для быстрой проверки.

UPD 04.08.2024.
Но при этом получение ASTFeatures из любой работы происходит в любом случае, так что пока эта логика с проверкой и вычислением хэша будет внедрена, может в дальнейшем оно будет как-то более хитро оптимизировано.