hirotasoshu / admin_panel_sprint_1

Проектная работа на первый спринт курса "Мидл Python-разработчик". Первая часть панели администратора на Django

admin_panel_sprint_1's Issues

ETL

В предыдущем модуле вы реализовали механизм для для полнотекстового поиска. Теперь улучшим его: научим его работать
с новой схемой и оптимизируем количество элементов для обновления.

Подсказки к выполнению задания ETL

Здесь представлены все подсказки для работы создания ETL, которые могут быть полезны при выполнении задания:

1. Прежде, чем броситесь выполнять задание, подумайте, сколько ETL процессов вам нужно.
2. Для построения ETL процесса советуем использовать корутины, чтобы их попробовать на практике, так как в теме по
   асинхронности вы с ними столкнетесь опять.
3. Ваше приложение должно уметь восстанавливать контекст и начинать читать с того места, где оно закончило свою работу.
4. При конфигурировании ETL процесса продумайте, какие вам нужны параметры для запуска приложения. Старайтесь оставлять
   в коде как можно меньше "магических" значений.
5. (Желательно) Сделать составление запросов в БД максимально обобщенным, чтобы не пришлось постоянно дублировать код.
   При обобщении не забывайте про то, что все передаваемые значения в запросах должны экранироваться.
6. Использование тайпингов позволит сократить время дебага и понимание кода ревьюерами, а значит работы будут проверяться
   быстрее.
7. Обязательно пишите, что делают функции в коде.
8. Для логгирования используйте модуль logging из стандартной библиотеки Python.

Желаем удачи вам в написании ETL. Вы обязательно сможете осилить это!

Миграция базы данных с Sqlite на PostgreSQL

Как только вы выполнили новые задания по работе с Postgres, к вам снова прибежал продакт. Он просит перенести уже заведённые карточки фильмы в новое хранилище, чтобы контент-менеджеры обновили недостающие описания, когда появится админка.

Совсем недавно вы спроектировали схему данных для Postgres, с которой гораздо проще работать, но SQLite всё так же живёт со сломанной схемой. Нужно аккуратно переложить данные, но при этом ничего не потерять при загрузке. Продакт верит, что вы сможете сделать это в ближайшие дни. Что ж, пришло время показать на что вы способны!

На первый взгляд задача выглядит простой: взять данные из одной базы и переложить в другую — даже бизнес-логики в этом нет! Но присмотритесь к задаче внимательно, ведь в ней полно важных моментов:

1. Нужно сохранить данные в пять разных таблиц в Postgres — film_work, genre, person, film_work_genre, film_work_person — из четырёх таблиц в SQLite — movies, movie_actors, actors, writers.
2. Нужно придумать, как проще всего извлечь данные из SQLite.

Совет: воспользуйтесь способом, который вы использовали в бесплатной части курса.

3. Нужно написать набор функций для преобразования данных из SQLite в Postgres. Это основная часть приложения, поэтому стройте всю программу от этой части.
4. В SQLite основная таблица — movies. Постарайтесь склеивать остальные таблицы с данными из таблицы movies — это может сильно помочь.
5. dataclass поможет быстро понять, где возникает ошибка при работе с данными.
6. Для генерации idв таблицах Postgres лучше всего использовать uuid.uuid4().
7. Подумайте, как можно сделать загрузку данных пачками, а не целиком.

7 задание со звёздочкой :)

Проектирование схемы БД

В проекте сейчас находится база данных с архитектурными ошибками.
В большинстве случаев технический долг тормозит развитие проекта и увеличивает его сложность. Избавьтесь от легаси в базе данных.

Для этого нам необходимо исправить ошибки, которые были допущены в схеме, с который вы работали в etl.

Проблемы, которые есть в текущей схеме, и оценка их критичности:

1. Отсутствие ключевых полей primary key у таблицы movie_actors. У вас не будет возможности искать записи, а также есть вероятность вставить дублирующие данные,
2. Денормализованные{target="_blank"} данные в таблице movies. Для некоторых практических ситуаций это может быть полезно: меньше join'ов между таблицами. Однако это усложняет обновление данных. Например, если была найдена ошибка в каком-то из популярных жанров,
3. Использование документноориентированной структуры в поле writers. Этот подход часто можно встретить в таких БД как MongoDB или Elasticsearch. SQLite — реляционная БД, поэтому предполагает иную работу с данными,
4. Сценаристы writers связаны с таблицей фильмов как ManyToMany, но без промежуточной таблицы. Это очень усложняет дальнейшую склейку join данных, чтобы, например, отправлять их в Elasticsearch.

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

Опечатка в README.md schema_design

Денормализованные{target="_blank"}

{target="blank"} явно попало по ошибке, либо должна быть полная ссылка.

Django. Пробуждение силы

На прошлых этапах мы получили 2 улучшения в системе:

• Новая архитектура базы данных,
• Динамическое обновление данных между базой данных и поисковым сервисом.

Необходимо разработать сервис, который позволит создавать и редактировать сущности из подготовленной схемы.

Основные этапы:

1. Создать структуру проекта Django.
2. Перенести в models схему, разработанную на ранних этапах.
3. Сравнить код, который был написан руками, c кодом, который генерирует Django автоматически,
4. Добавить механизмы работы с models для контент-менеджера.

Основные сущности

Основные сущности, которые должны присутствовать в сервисе.

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

• Пользователь — электронная почта, логин, пароль, дата регистрации, система прав.

• Фильм – заголовок, содержание, дата создания, возрастной ценз, режиссеры, актеры, сценаристы, жанры, ссылка на файл.

• Сериал - заголовок, содержание, даты создания, режиссеры, актеры, сценаристы, жанры, ссылка на файл.

• Актер — Имя, фамилия, его фильмы

• Режиссер — Имя, фамилия, его фильмы

• Сценарист — Имя, фамилия, его фильмы

• Жанр — Описание

Требования к объему данных

Эти требования необходимы для проверки работы индексов в вашей базе. При тестировании приложения с небольшим количеством записей мы не сможем проверить, правильно ли выполнена часть задания с индексами.