/FileSearchSystem

Primary LanguagePython

FileSearchSystem

HTTP-сервер для поиска файлов в локальной файловой системе


Требования

  • Docker (для redis)
  • Java 7+ на компьютере (для библиотеки tika)
  • PostgreSQL
  • Python

Запуск

  1. Перейти в корень проекта
  2. Создать и активировать виртуальное окружение
    • python -m venv .venv
    • source .venv/Scripts/activate
  3. Установить зависимости
    • pip install -r requirements.txt
  4. Создать файл .env, основываясь на .env-example
  5. Запустить redis через команду docker
    • docker pull redis
    • docker run --name redis-server -d redis
  6. Запустить celery в дополнительном окне терминала
    • celery -A service.extract_text.celery_app worker -P solo
  7. Запустить сервер
    • python main.py

После выполнения вышеописанных действий можно перейти по адресу http://localhost/api/docs для более удобной работы с сервисом.


Запросы


Тестирование

  1. Убедитесь, что вы прошли пункты 1-7 инструкции запуска
  2. Находясь в корневой директории, напишите команду
    • pytest .

Сессия тестирования займёт ~30 секунд.


Алгоритм работы сервиса


FileSearchSystem
├── api                         
│   ├── endpoints                        
│       ─── search_endpoint.py          # обработка запросов на создание поиска и получение результатов
│       ─── health_check.py             # эндпойт для тестирования соединения
│   ─── routers.py                      # fastapi router с эндпойнтами для экспорта в main.py
├── db 
│   ├── models                        
│       ─── search_table.py             # модель для работы с БД через ORM
│   ├── repositories                    
│       ─── search_db.py                # создание и выгрузка записи из БД
│   ─── connection.py                   # подключение к БД
├── schemas                      
│   ─── search_schema.py                # pydantic схема для работы с данными из/для эндпойнтов
├── service                         
│   ─── extract_text.py                 # поиск текста в файлах, полученных из get_all_files.py
│   ─── get_all_files.py                # получение файлов, подходящих по всем параметрам
├── utils
│   ─── check_path.py                   # проверяем корректность переданной в .env папки для поиска 
│   ─── check_normal_files.py           # проверяем обычные файлы (не внутри zip-архивов)
│   ─── check_zip_files.py              # проверяем файлы внутри zip-архивов
│   ─── compare.py                      # python словарь для сравнения данных
│   ─── create_test_dir.py              # создание структуры файлов для тестирования
├── tests                         
│   ├── endpoints_test                  # набор тестов для эндпойнтов
│       ─── health_check_test.py
│       ─── search_endpoint_test.py
│   ─── conftest.py
│   ─── db_test.py                      # тестирования базы данных
│   ─── data.py                         # шаблоны данных для тестирования
├── config.py                           # python класс для получения переменных окружения 
├── main.py                             # создание fastapi application и точка входа
├── requirements.txt
├── pytest.ini                          # настройки для работы pytest 
├── .env
├── README.md

Схема работы POST

  1. Пользователь отправляет данные на /search
  2. Данные валидируются/создаются дефолтные с помощью pydantic
  3. Вызывается функция для добавления в БД
  4. Данные из pydantic-модели распаковываются в модель для БД
  5. Пользователь получает ID для набора настроек в формате UUID4

Особенности

  • возможность последовательно вызывать /search с одинаковыми данными. Сделано из предположения, что поскольку мы работаем с файловой системой, то она может меняться, но при этом у нас не предусмотрено эндпойнта для удаления или перезаписывания результатов поиска по search_id. Один раз вызвав GET для search_id, результат записывается в БД (redis) и последующие вызовы этого search_id будут давать такой же результат. Для возможности получить новые результаты поиска с теми же условиями, нужно создать новый search_id и передать в GET.

Схема работы GET

  1. Пользователь передаёт search_id
  2. Проверяется соответствие стандарту UUID4
  3. Проверяется статус задачи в celery. Если задача уже выполнена, то возвращаем результат из БД для результатов redis
  4. Если задача в процессе выполнения, то она в БД для отслеживания redis. В таком случае возвращаем шаблон ответа для случая ещё не завершённого процесса поиска
  5. Если search_id получен впервые, то возвращаем шаблон ответа для случая ещё не завершённого процесса поиска, а также проверяем наличие в БД
  6. Выгрузка данных для поиска из БД
  7. Передача в функцию, проверяющая все файлы в TARGER_DIRECTORY из .env на соответствие параметрам поиска (кроме текста внутри файлов)
  8. Затем проверяем наличие заданного текста внутри файлов (любого формата) при помощи библиотеки tika
  9. Возвращаем результат (только при повторном вызове с тем же search_id)

Особенности

  • Реализована проверка zip-архивов (кроме тех, которые уже находятся внутри zip-архивов)