Благодарю за видео! Сама идея заворачивать весь view в транзакцию очень плохая, так как там может быть не только работа с базой, но ещё какие-то шаги. Например, rest-запрос на какой-то сервис (возможные проблемы с сетью или нагруженностью третьего сервиса, долгий ответ). И пока эти этапы будут производиться у вас будет висеть открытая транзакция в базе, что очень плохо скажется на производительности. Но, если вы обернете в транзакцию лишь сервисный слой, который работает сугубо с базой, у вас транзакция откроется только в момент работы с базой и закроется в нужный момент. Плюс во view вы сможете поймать исключение которое было сброшено в сервисном слое, ибо оно уже откатило транзакцию
Спасибо! Накидываю темы, которые было бы круто послушать в твоей интерпретации: 1. Сигналы. Как их использовать, когда полезны. 2. Работа с ORM и с raw queries. Когда что использовать, какие-то фишки со сложными запросами. 3. Работа с сессиями 4. Работа с auth. Создание кастомного юзера, токены, свои менеджеры для него.
Сюда же накину, если автор не против. 5. Работа с миграциями, data миграции, миграции в команде (git) и миграции при работе с несколькими основными ветками staging и prod например (git). 6. Таски (celery etc.) - соответственно фишки, кроны, чейны и т.д. 7. Кэш - польза, применение и т.д. Прошу прощения если какая-то из тем уже есть на канале.
1. Сигналы - отстой, не надо их использовать:) Заколебаться потом искать, кто где меняет данные. 2. Что тут было бы интересно? Я предпочитаю использовать джанговых ORM на простых запросах и писать сырой SQL на сложных запросах, но в целом раз уж юзать ORM, то стоило бы и на сложных запросах использовать ORM (бенефиты автоматического рефакторинга IDE будут доступны и тп). Но я не могу заставить себя учить очередной птичий язык очередного ORM плюс не доверяю ему на сложных запросах. В оракловой БД есть подсказки для БД, которые вставляются в SQL, и подсказывают оптимизатору, как лучше выполнять запрос. Какой тут ORM:) В постгрес такого нет, но я всё равно скептически отношусь к ORM для чего-то сложного. 3. Сессии. Ну, они есть, джанговый механизм вполне юзабелен и описан docs.djangoproject.com/en/3.2/topics/http/sessions/, что по нему интересно? 4. Auth и кастомный юзер - да просто AbstractUser реализуй и в путь:) docs.djangoproject.com/en/3.2/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project 5. Миграции. Вопрос интересный, но мне хочется больше деталей вопроса. Миграции в команде? Ну мержить придется, тут других выходов нет, кажется:) 6. Celery - злющее зло, все не доходят руки выпилить его к едрене фене с проектов, но однажды точно дойдут. Cron лучше, чем celery beat. Для асинхронных задач, запускаемых из джанго вьюшек, надо найти какую-то замену Celery, сам Celery не нравится. И DRF тоже не нравится. Но Celery больше:)
При работе с транзакциями также полезно использовать метод on_commit. Позволяет совершить действия после того, как транзакция закоммитилась и объект действительно записался в бд. Ну и по мне все-таки обрабатывать транзакции явно в коде, а не передавать глобально в настройки
Это единственный из каналов, на которые я подписан, на котором ни одного выпуска не пропускаю. И у которого рейтинг роликов 15% - это вообще как так? Обычно если 5% значит годно, 10% - топчик, а тут 15%? Космический канал с космическим автором. Надеюсь на долго и счастливо ) продолжайте пожалуйста
@@expollux да просто посмотри, какой у ролика % лайков по отношению к количеству просмотров. На сейчас 821 лайк к 7600 просмотров - примерно 11%. Это очень много.
Как по мне более простым решением будет обернуть в блок try except контекстный менеджер с выполнением всех необходимых запросов. Я проверял и вроде как работает абсолютно идентично тому, что показанно в видео.
Бомба! Большое спасибо. Тема очень актуальная и нигде ранее не видел такого способа. Буду юзать. Ну и на flask теперь буду пробовать такое реализовать.
Однозначно. Именно поэтому любой фреймворк - говно, потому что надо знать кучу магии которая происходит внутри фреймворка, чтобы написать программу чуть сложнее чем hello world. А если самому стартовать транзакции никакой фреймворк нафик не нужен
@@t0digital ну тут вопрос решается достаточно просто. Прежде чем начать реализовывать кусок кода необходимо включить головушку, посидеть подумать, хорошенько расписать задачу и только потом кодить :)
@@pin689 чтобы написать программу чуть сложнее чем hello world - фреймворк и не нужен, а не любой фреймворк - говно. Фреймворк относится к стеку знаний, обладая которыми вы можете прийти в проект и быстрее начать работать над задачами. Он уменьшает объем проектных знаний, которые кому-то вам потребуется объяснить и кучу особенностей как там все написано в каждом конкретном проекте, какие библиотеки используются, когда и какие вызывать, костыли и т.п. Фреймворк задает структуру как писать, где писать: компоненты так и там, вьюхи там, контроллеры там. Т.е. задает частичные ограничения снижая вероятность написания чего-то своего непонятно где и как попало. И чем больше свободы действий, тем больше увеличиваете объем проектных знаний, которые будут накапливаться. Они вам вряд ли пригодятся в другом проекте, а человек, который прийдет из вне будет 3 месяца изучать всю кухню структуры проекта. Там и без этого хватит бизнес логики в которую придется вникать, добавлять сюде еще самописные костыли со структурой, которая будет только в этом проекте - заведомо усложнять жизнь другим и себе в будущем при разрастании проекта. Обладая знаниями фреймворка вы уже придя в проект понимаете, чем будете пользоваться и как. Вам эту огромную часть не нужно уже объяснять, чтобы вы начали писать код. Как-то так приблизительно.
очень доступно добрый ты человек :) в плане основной темы о транзакциях ! но перебор когда файл урлов инклюднул ссыль с другого файла урлов в другом подкаталоге - если я правильно понял. ибо мне это напомнило как заумные ООП-щики сделали простую прогу на 40 классов и сами потеряли нить в своей писанине)) потом мой друг переписал их творение в 2 класса по 10 строчек и она заработала - он просто свёл их классы. я то понимаю чем больше каскадов тем сильнее абстрагирование - но как бы рекурсии не вышло при 40 классах между 12-м классом и 27-м :)
чтобы выйти из sqlite shell или из любой другой интерактивной оболочки (zsh,sh,bash,......) достаточно послать управляющую последовательность exit, то есть просто нажать Ctrl+D
"Явное лучше неявного" /The Zen of Python/. Именно поэтому делать такую миддлварь и "доносить до членов команды" в серьезном проекте я бы не стал, а использовал бы контекстный менеджер. Состав команды может меняться, проект может переехать в другой отдел или передан на аутсорс. Где-то в этом процессе сакральное знание (сколько еще подобных неявных моментов появится в проекте?) затеряется и не донесется.
Вероятность, что кто-то забудет обернуть что-то в транзакцию - имхо сильно выше. А что до "явное лучше неявного" - почему бы тогда не разбирать пришедший хттп запрос вручную, а то что это его кто-то неявно разбирает за нас, непорядочек:) собирать хттп ответ тоже самим, заголовки проставлять. Джангу в топку, у нее там под капотом стооолько неявного :)
С мидлварами интересный прием, спасибо. Но вот когда я работал с транзакцией, у меня ещё мудренее ошибка была. При откате транзакции не применяются изменения в экземпляре класса модели. В базе у нас отказ сделан, а при обращении к атрибутам модели отката как бы нет.
Добрый вечер, очень крутой контент, давно смотрю Вас, было бы круто, если расскажите, как вы провайдите сервисы в ui слой, на примере Django. ЛАЙК, ЧТОБЫ УВИДЕЛ, ОЧЕНЬ ИНТЕРЕСНАЯ ТЕМА ))
Спасибо большое. Полезно и интересно. Что это у Вас за плагинчик в Nvim такой? Чё то он шибко умный этот линт. ;) Кстати, а вот если WEB приложение отправляет запрос в базу данных и она такая большая, что на получение информации надо несколько секунд. Как добиться чтобы приложение не фризелось и выводило пользователю страничку с какой нибудь крутящейся байдой типа «подождите, выполняю запрос?»
Спасибо! Интересно и полезно. Пару вопросов по рабочему процессу. Почему Neovim, раньше был просто vim, и что за плагин такой, в результате чего получается IDE?
Автор, будет ли в Вашем исполнении Санта Лючия на итальянском? Как будто Энрико Карузо реинкарнировался и теперь ведет канал про Пейтон. Та же форма лица, черты. Да даже улыбка такая же.
Уважаемый ,Диджитализируй!. А в коде джанго не стоит ли флажок "сохранять запросы в БД сразу как внесли их " при чем еще при ее открытии ,как у API sqlite3 в connect(....,isolation_level=None)? Или не отсутствует ли метод "отката" после ошибки ? Может проще в потрохах джанги исправить ? П.С. Сам место создания и открытия БД в коде не нашел,у меня с инглишом не очень.
Если уверены, что никто нигде не забудет обернуть нужный функционал в транзакцию - то да, это будет работать более эффективно, но с бОльшим риском однажды получить неконсистентные данные в БД.
@@ihorkovryhin1767 ничего нигде не делать легче, чем везде делать, не находите? Взять правило не обрабатывать ошибки, которые должны улететь клиенту - легче, чем везде реализовывать транзакции
@@t0digital Обрабатываем ошибки в проекте мы довольно часто и с учетом, что работа с базой может быть в глубине различных вызовов понять, что мы обработали ошибку которую не нужно было обрабатывать весьма не тривиальная вещь. Я не говорю что одно решение лучше другого, просто хотел обратить внимание на то, что не все так однозначно хорошо. Явное лучше чем не явное. Атомарные запросы хороши для простых проектов, но чем сложнее наша система, тем больше подводных камней будет вылазить. Когда система разрастется до того уровня, что пора бы уже контролировать транзакции и не делать их длинною в жизнь, то добавить транзакции будет весьма не тривиальной задачей.
@@ihorkovryhin1767 ну куча запросов к бд в 1 http запросе это все равно плохо, даже не применительно к транзакциям, и куча долгих запросов к БД в рамках 1 хттп запроса это тоже плохо - стартовать транзакции на все запросы это особенно плохо, когда БД запросов много в каждом http запросе и они долгие, база начнет вешать всё
Так если прям надо во вьюхе отловить ошибку, то можно конкретно для этой вьюхи или декоратор прописать или контекстный менеджер атомарности транзакции указать. Не?
Немного оффтопный вопрос. Как используя ДРФ и JS-фронт работать с аутентификацией? Точнее, делать эндпоинты для получения себя, а в АПИ прокидывать уникальный идентификатор пользователя?
Спасибо за видео, очень полезная информация! Но у меня дополнительный вопрос. Подобное поведение с неоткаченной транзакцией при отловленном в try/except исключении проявляется только если ATOMIC_REQUESTS активирован (True)? Или это вообще стандартное поведение при любом объявлении миграции, включая декоратор и with?
Спасибо за видео. Получается, что Atomic requests стоит использовать не для всего проекта, а только для тех приложений (задач), в которых нужны транзакции? К примеру, биллинг.
Спасибо! Да, я хочу ещё донастроить и потом сделаю материал по настройке, сейчас линтер ругается в одном месте, где нет ошибок, хочу выяснить почему и как пофиксить
Не понял про последний вариант, там запись в БД вообще происходит(открывается транзакция СУБД) или нет, а откат как выполняется? Из кода на видео это не ясно. Такое чувство, что тут типа ленивого выполнения кода, т.е. сперва обе функции "как-бы" выполняются(без реальной записи в БД) и если все ОК, то оно выполнит запись в БД(создаст соотв-ие транзакции и т.п.).
Здравствуйте! Вопрос немного не по теме, хотел бы услышать ваше мнение. Работаю разработчиком БД, в работе используем Oracle, Teradata, Greenplum, Informatica(ETL). Опыт работы - 1 год. Знаю ДС на хорошем уровне(изначально им занимался, но предложили другую должность). Получаю в целом неплохо, 150+. Просто про базы данных всегда так вскользь упоминают, про ETL тоже особо не говорят. Как вы считаете, не стоит ли сменить направление, если говорить о перспективах и дальнейшей востребованности. Спасибо за ответ!
Привет! Спецы БД, ETL и тп зарабатывают нормально. Oracle, большие корпорации, нормально, если это ваше:) А вот если чувствуете, что это не ваше (неуютно себя чувствуете в корпорации или таких проектах для enterprise бизнеса), то можно подумать о переходе. Надо заниматься тем, что драйвит. Если текущее драйвит - отлично, если нет - ищите, что будет драйвить.
Технически можно вернуть что угодно, конечно. 500ка это означает неожиданную ошибку сервера, если обрабатываемый сценарий именно такой, значит, стоит вернуть 500ку. Но фронтенд может ожидать всегда 200 или как-то не так обрабатывать 500ку, как вам нужно, такое тоже бывает, зависит и от фронтенда
Отправлять клиенту 500 ошибки такое себе решение. 500 ошибка - это ошибка сервера, а это значит, что если сервер падает на таком запросе, и такое поведение не ожидаемо, значит код работает неправильно. Для таких случаев нужно использовать Sentry, или что-то подобное, где разработчики могут сами видеть ошибки своих серверов. Если сентри использовать неохота, то этот middlware использовать для таких целей. Иначе, клиенту возвращать 4xx ошибки
Еще есть вариант с транзакциями - это сессии SQLAlchemy, реализующие шаблоны Unit Of Work и Identity Map. Упрощенно так: try: u = Users(email=user_email, psw=hash) db.session.add(u) db.session.flush() p = Profiles(name=user_name, user_id=u.id) db.session.add(p) db.session.commit() except: db.session.rollback()
А что на счёт транзакций с переключением базы данных? (Что то типа SAAS проекта) Допустим у нас есть одна база, назовём её main, где есть таблица с accounts/clients, и есть N других баз client_1, client_2, ..., это базы клиентов. Нам надо списать с одного нашего клиента деньги и записать другому нашему клиенту (соответственно в client_1/client_2/... есть одинаковые таблички, к примеру wallet). Ну и, допустим, у нас MySQL база. Как отработают транзакции в таком случае? Или, как это реализовать по-нормальному без того, что у тебя есть метод, который меняет коннекшин к базе? Вроде слышал одним ухом когда-то, как взрослые Senior-девелоперы говорили на перекуре, что в MySQL не поддерживается такая штука. Нельзя завернуть в транзакцию такое изменение, потому что при переключении коннекшина автоматически происходит коммит в БД, и получится что ты с одного снял, а другому не записал. ОК, если в этом принимает участие 2 базы, на это можно придумать костыль какой то, но если 10, тут уже по-сложнее будет. Очень хочу услышать какое то разумное объяснение что и как делать :) Спасибо
Транзакции же отлавливают в целом необработанный эксепшн. А базы это сторонние зависимости, к которым обращение идет через слой нашего кода. Соответственно, вне зависимости от этой зависимости, слой кода будет возвращать эксепшн при ошибке - соответственно сработает и обработка транзакций. Если сказал дичь - не бейте палками, я фронтендер :)))
Немного не понял. То есть, это не транзакции баз данных? А транзакции именно в коде? Что то у меня не сошлось :) Я почему то думал, что оно оборачивает все запросы (запросы к БД, insert/delete/update/select), которые есть в методе в транзакцию БД
Это называется распределенная транзакция, транзакция, затрагивающая несколько независимых друг от друга систем. В целом очень сложная штука. В настоящее время есть два основных подхода, two phase commit и синхронизация на основе событий (event). В основном применяют event подход, он более гибкий и масштабируемый. Вкратце это работает так. В базе main создается таблица events. В одной транзакции вместе с изменением accounts добавляется запись в таблицу events в базе main. Далее есть процесс-координатор, который следит за таблицей events. При появлении там новой записи он блокирует эту запись и пытается сделать изменения в другой БД client_1/client_2, затем удаляет запись из таблицы events БД main, или меняет статус на обработанное. Сложность реализации координатора в том что во-первых он должен обрабатывать записи из таблицы events (тоесть менять из статус или удалять, в результате), а во-вторых, менять статус только тогда когда будет уверен что другая система, БД client_1/client_2 точно обработала запрос, поменяла у себя данные. Примерно так. Минус в том, что данные отражаются в других системах client_1/client_2 не сразу, а с задержкой. Но от этого практически никуда не деться, лучше пока не придумали. Все с этим вынуждены мириться, с этой задержкой синхронизации баз данных. Плюс в том что это масштабируется. Если 10 баз, запускается 10 координаторов, каждый работает со свой базой. И даже несмотря на то что они не будут синхронизированы одновременно, все равно, наступит момент, когда все они будут синхронизированы. Этот момент называют ещё eventual consistency
Оп-па! А я и не знал, что можно в конфиге для БД включить транзакции! У меня везде через менеджер контекста это реализовано. Можно немного оптимизироваться! ;-) Спасибо! ) А вот if request.path == ... в мидлвари, на мой взгляд, не очень хорошая идея. Этак она чрезмерно распухнуть может с кучей elif после if...
А зачем может понадобится под каждую вьюшку в проекте делать отдельный if в этой мидлваре? У меня нет идей. Есть, например, функционал платежей, он лежит в приложении payments, урлы начинаются с /payments, вот для них можно настроить мейлинг об отдельных ошибках админам, например
@@t0digital, только тут, скорее, под приложение (в джанговской терминологии), так-то у меня тоже нет идей. Я однажды попал в ситуацию, когда мидлварь оказалась "тяжелее" всех вьюх. Там от меня ничего не зависело, но с тех пор старательно минимизирую код в middleware, когда приходится их писать. ;-) Мэйлингом у меня логгер занимается, когда это необходимо, хэндлер с логлевелом critical... Единственный момент, где там можно выстрелить себе... хм-м... повыше колена - забыть raise после logger.critical(). Разве что сохранение трейсбэков (всех исключений) вынесено в мидлварь.
Смотрю я на это из точки Java,C# и у меня волосы седеют и активно шевелятся на голове. Чем дальше смотрю питон тем больше утверждаюсь что народ не оборачивает ORM своим далом, а про бизнес логика это что то из области фантастики.
Благодарю за видео! Сама идея заворачивать весь view в транзакцию очень плохая, так как там может быть не только работа с базой, но ещё какие-то шаги.
Например, rest-запрос на какой-то сервис (возможные проблемы с сетью или нагруженностью третьего сервиса, долгий ответ).
И пока эти этапы будут производиться у вас будет висеть открытая транзакция в базе, что очень плохо скажется на производительности.
Но, если вы обернете в транзакцию лишь сервисный слой, который работает сугубо с базой, у вас транзакция откроется только в момент работы с базой и закроется в нужный момент. Плюс во view вы сможете поймать исключение которое было сброшено в сервисном слое, ибо оно уже откатило транзакцию
Вот это было полезно,прям по работе.
Огромное спасибо за вашу работу!
Спасибо! Накидываю темы, которые было бы круто послушать в твоей интерпретации:
1. Сигналы. Как их использовать, когда полезны.
2. Работа с ORM и с raw queries. Когда что использовать, какие-то фишки со сложными запросами.
3. Работа с сессиями
4. Работа с auth. Создание кастомного юзера, токены, свои менеджеры для него.
Сюда же накину, если автор не против.
5. Работа с миграциями, data миграции, миграции в команде (git) и миграции при работе с несколькими основными ветками staging и prod например (git).
6. Таски (celery etc.) - соответственно фишки, кроны, чейны и т.д.
7. Кэш - польза, применение и т.д.
Прошу прощения если какая-то из тем уже есть на канале.
Ох, это будет топ-годнота!
Вангую перенаправят вас с вашими аппетитами на курс)) Но темы класс, плюсую)
1. Сигналы - отстой, не надо их использовать:) Заколебаться потом искать, кто где меняет данные.
2. Что тут было бы интересно? Я предпочитаю использовать джанговых ORM на простых запросах и писать сырой SQL на сложных запросах, но в целом раз уж юзать ORM, то стоило бы и на сложных запросах использовать ORM (бенефиты автоматического рефакторинга IDE будут доступны и тп). Но я не могу заставить себя учить очередной птичий язык очередного ORM плюс не доверяю ему на сложных запросах. В оракловой БД есть подсказки для БД, которые вставляются в SQL, и подсказывают оптимизатору, как лучше выполнять запрос. Какой тут ORM:) В постгрес такого нет, но я всё равно скептически отношусь к ORM для чего-то сложного.
3. Сессии. Ну, они есть, джанговый механизм вполне юзабелен и описан docs.djangoproject.com/en/3.2/topics/http/sessions/, что по нему интересно?
4. Auth и кастомный юзер - да просто AbstractUser реализуй и в путь:) docs.djangoproject.com/en/3.2/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project
5. Миграции. Вопрос интересный, но мне хочется больше деталей вопроса. Миграции в команде? Ну мержить придется, тут других выходов нет, кажется:)
6. Celery - злющее зло, все не доходят руки выпилить его к едрене фене с проектов, но однажды точно дойдут. Cron лучше, чем celery beat. Для асинхронных задач, запускаемых из джанго вьюшек, надо найти какую-то замену Celery, сам Celery не нравится. И DRF тоже не нравится. Но Celery больше:)
@@t0digital А чем конкретно Celery + beat не нравится? У нас пара десятков воркеров с ним, свои задачи выполняет стабильно.
Так и знал, что будет топовый видос!)
Очень интересно, спасибо за труд!
Никогда и ни за что не отдам консистентность данных каким то левым миддл-чувакам! Спасибо за видео, плотность информации на единицу времени поражает.
При работе с транзакциями также полезно использовать метод on_commit. Позволяет совершить действия после того, как транзакция закоммитилась и объект действительно записался в бд. Ну и по мне все-таки обрабатывать транзакции явно в коде, а не передавать глобально в настройки
Это единственный из каналов, на которые я подписан, на котором ни одного выпуска не пропускаю. И у которого рейтинг роликов 15% - это вообще как так? Обычно если 5% значит годно, 10% - топчик, а тут 15%? Космический канал с космическим автором. Надеюсь на долго и счастливо ) продолжайте пожалуйста
Что за рейтинг роликов? Где его посмотреть?
@@expollux да просто посмотри, какой у ролика % лайков по отношению к количеству просмотров. На сейчас 821 лайк к 7600 просмотров - примерно 11%. Это очень много.
Хоть и не связывался с транзакциями, но видос - топ! Побольше такого контента. Спасибо тебе!
Чувак, у тебя очень крутой канал. Смотрю тебя уже больше года, очень интересный материал и отличная подача.
Спасибооо! Буду продолжать!
Спасибо мужик! Очень достойное видео. Для себя подчерпнул много полезного!
Рад, что полезно!
Мне как для новичка эта инфа является неоценима полезной. Thx
Очень круто!
Ждём больше таких историй!
Полезно. Как раз велосипедил это на своём проекте.
И мастер-класс по Виму - бесконечно можно повторять 😎😎😎
Как по мне более простым решением будет обернуть в блок try except контекстный менеджер с выполнением всех необходимых запросов. Я проверял и вроде как работает абсолютно идентично тому, что показанно в видео.
Как всегда ТОП!
Вы лучший, на данный момоент я начинающий программист, ваши ролики макимально полезны, они реально поднимают уровень))))
Благодарю за видос и ваш труд🔥😎
2:03 не поиметь проблем, а что-бы проблемы не поимели. Видос топ.
пока "Не мой уровень дорогой")) но когда нибудь точно пригодится. спасибо!
Спасибо большое. Почаще бы видео, всегда очень интересно
Бомба! Большое спасибо. Тема очень актуальная и нигде ранее не видел такого способа. Буду юзать. Ну и на flask теперь буду пробовать такое реализовать.
Офигенно полезное и поучительное повествование. Спасибо огромное!
Достойный материал, спасибо!
Очень полезное видео! Спасибо, буду учитывать эти моменты при работе с транзакциями в джанге.
Имхо, транзакции лучше стартовать, коммитеть и откатывать явно в коде. Вешать старт транзакции на все эндпоинты проекта - ну так себе идея.
Если есть уверенность, что никто нигде не забудет обернуть нужный функционал в транзакцию - то да
Однозначно. Именно поэтому любой фреймворк - говно, потому что надо знать кучу магии которая происходит внутри фреймворка, чтобы написать программу чуть сложнее чем hello world. А если самому стартовать транзакции никакой фреймворк нафик не нужен
@@t0digital ну тут вопрос решается достаточно просто. Прежде чем начать реализовывать кусок кода необходимо включить головушку, посидеть подумать, хорошенько расписать задачу и только потом кодить :)
@@pin689 чтобы написать программу чуть сложнее чем hello world - фреймворк и не нужен, а не любой фреймворк - говно. Фреймворк относится к стеку знаний, обладая которыми вы можете прийти в проект и быстрее начать работать над задачами. Он уменьшает объем проектных знаний, которые кому-то вам потребуется объяснить и кучу особенностей как там все написано в каждом конкретном проекте, какие библиотеки используются, когда и какие вызывать, костыли и т.п. Фреймворк задает структуру как писать, где писать: компоненты так и там, вьюхи там, контроллеры там. Т.е. задает частичные ограничения снижая вероятность написания чего-то своего непонятно где и как попало. И чем больше свободы действий, тем больше увеличиваете объем проектных знаний, которые будут накапливаться. Они вам вряд ли пригодятся в другом проекте, а человек, который прийдет из вне будет 3 месяца изучать всю кухню структуры проекта. Там и без этого хватит бизнес логики в которую придется вникать, добавлять сюде еще самописные костыли со структурой, которая будет только в этом проекте - заведомо усложнять жизнь другим и себе в будущем при разрастании проекта. Обладая знаниями фреймворка вы уже придя в проект понимаете, чем будете пользоваться и как. Вам эту огромную часть не нужно уже объяснять, чтобы вы начали писать код. Как-то так приблизительно.
Спасибо!) отличное видео!
Ох Гуру! Респект Вам
Информация от Мастера! Респект и благодарность!
Благодарю за видео.
Только начел учить django - не всё понятно, но очень интересно)))..
Очень полезно! Спасибо!
Большое спасибо, Алексей, очень полезное видео!
очень доступно добрый ты человек :) в плане основной темы о транзакциях ! но перебор когда файл урлов инклюднул ссыль с другого файла урлов в другом подкаталоге - если я правильно понял. ибо мне это напомнило как заумные ООП-щики сделали простую прогу на 40 классов и сами потеряли нить в своей писанине)) потом мой друг переписал их творение в 2 класса по 10 строчек и она заработала - он просто свёл их классы. я то понимаю чем больше каскадов тем сильнее абстрагирование - но как бы рекурсии не вышло при 40 классах между 12-м классом и 27-м :)
Многим огромное кол-во нервов сохранил!)
Полезное видио, спасибо 😉
Хотел уточнить по курсу, оно подойдёт разработчику, который уже год в разработке или это больше для начинающих?)
Всем полезно, кто незнаком сильно с предметом обсуждения
Мега полезный материал. Огромное спасибо🔥🔥
Стакан на фоне - красноречив) И придает фактуру происходившей дичи))
реализация без MIDDLEWARE:
def home(request):
try:
with transaction.atomic():
first()
second()
return JsonResponse({'success': True})
except Exception as e:
return JsonResponse({'success': False, 'error': str(e)})
Прекрасно! Спасибо большое!!
Очень полезное видео!!!!
отличный видос, поменьше багов автору на работе и удачи!
Спасибооо!
Отличное видео, не знал, что можно таким образом зафейлить транзакцию. Большое спасибо!
кстати, отличная идея запилить серию видосов с вариантами неочевидных выстрелов в ногу - "как неожиданно зафейлить {something}"
Спасибо за ролик! Очень полезный ролик
чтобы выйти из sqlite shell или из любой другой интерактивной оболочки (zsh,sh,bash,......) достаточно послать управляющую последовательность exit, то есть просто нажать Ctrl+D
"Явное лучше неявного" /The Zen of Python/. Именно поэтому делать такую миддлварь и "доносить до членов команды" в серьезном проекте я бы не стал, а использовал бы контекстный менеджер. Состав команды может меняться, проект может переехать в другой отдел или передан на аутсорс. Где-то в этом процессе сакральное знание (сколько еще подобных неявных моментов появится в проекте?) затеряется и не донесется.
Вероятность, что кто-то забудет обернуть что-то в транзакцию - имхо сильно выше.
А что до "явное лучше неявного" - почему бы тогда не разбирать пришедший хттп запрос вручную, а то что это его кто-то неявно разбирает за нас, непорядочек:) собирать хттп ответ тоже самим, заголовки проставлять. Джангу в топку, у нее там под капотом стооолько неявного :)
документацию нормальную пишите к проекту и все будет ок
С мидлварами интересный прием, спасибо. Но вот когда я работал с транзакцией, у меня ещё мудренее ошибка была. При откате транзакции не применяются изменения в экземпляре класса модели. В базе у нас отказ сделан, а при обращении к атрибутам модели отката как бы нет.
Можно Видео про масштабирование базы на нескольких серверах ?
Огонь 🔥
Добрый вечер, очень крутой контент, давно смотрю Вас, было бы круто, если расскажите, как вы провайдите сервисы в ui слой, на примере Django. ЛАЙК, ЧТОБЫ УВИДЕЛ, ОЧЕНЬ ИНТЕРЕСНАЯ ТЕМА ))
Спасибо большое. Полезно и интересно. Что это у Вас за плагинчик в Nvim такой? Чё то он шибко умный этот линт. ;) Кстати, а вот если WEB приложение отправляет запрос в базу данных и она такая большая, что на получение информации надо несколько секунд. Как добиться чтобы приложение не фризелось и выводило пользователю страничку с какой нибудь крутящейся байдой типа «подождите, выполняю запрос?»
Нужно помнить что после integrity error или database error внутри транзакции, обращение к базе вызовет исключение
Блин, спасибо!!
Не понимали, почему у нас на проекте периодически что-то падало
Миллиард лайков! Спасибо большое
Спасибо! Интересно и полезно. Пару вопросов по рабочему процессу. Почему Neovim, раньше был просто vim, и что за плагин такой, в результате чего получается IDE?
Это pyright lsp server. Сделаю материал по настройке
@@t0digital Очень ждём)
реально полезное видео! спасибо!
Автор, будет ли в Вашем исполнении Санта Лючия на итальянском?
Как будто Энрико Карузо реинкарнировался и теперь ведет канал про Пейтон.
Та же форма лица, черты. Да даже улыбка такая же.
Уважаемый ,Диджитализируй!. А в коде джанго не стоит ли флажок "сохранять запросы в БД сразу как внесли их " при чем еще при ее открытии ,как у API sqlite3 в connect(....,isolation_level=None)? Или не отсутствует ли метод "отката" после ошибки ? Может проще в потрохах джанги исправить ? П.С. Сам место создания и открытия БД в коде не нашел,у меня с инглишом не очень.
Спасибо. Хотелось бы увидеть про работу Jsonb из Postgresql в питоне. В ютубе очень мало видео на эту тему ❗️
В чем проблема взять управляемую транзакцию, и перед success делать commit() а в except вызывать rollback() ?
Большое спасибо за инфу!!!
Обработка транзакций через settings, кажется, плохим паттерном. Надо ручками, явно, обрабатывать транзакции.
Если уверены, что никто нигде не забудет обернуть нужный функционал в транзакцию - то да, это будет работать более эффективно, но с бОльшим риском однажды получить неконсистентные данные в БД.
@@t0digital Так у Вас та же проблема. Все будет работать если все будут помнить что ошибки ловить нельзя. В чем разница?
@@ihorkovryhin1767 ничего нигде не делать легче, чем везде делать, не находите? Взять правило не обрабатывать ошибки, которые должны улететь клиенту - легче, чем везде реализовывать транзакции
@@t0digital Обрабатываем ошибки в проекте мы довольно часто и с учетом, что работа с базой может быть в глубине различных вызовов понять, что мы обработали ошибку которую не нужно было обрабатывать весьма не тривиальная вещь. Я не говорю что одно решение лучше другого, просто хотел обратить внимание на то, что не все так однозначно хорошо. Явное лучше чем не явное. Атомарные запросы хороши для простых проектов, но чем сложнее наша система, тем больше подводных камней будет вылазить. Когда система разрастется до того уровня, что пора бы уже контролировать транзакции и не делать их длинною в жизнь, то добавить транзакции будет весьма не тривиальной задачей.
@@ihorkovryhin1767 ну куча запросов к бд в 1 http запросе это все равно плохо, даже не применительно к транзакциям, и куча долгих запросов к БД в рамках 1 хттп запроса это тоже плохо - стартовать транзакции на все запросы это особенно плохо, когда БД запросов много в каждом http запросе и они долгие, база начнет вешать всё
Как продолжение, хотелось бы услышать мнение автора на реализацию атомарности при использовании СУБД postgresql и GEVENT в джанге
Привет) классные видео. Будет ли что-нибудь по wagtail? мы на работе почти все проекты в нем делаем) на чистом джанго почти ничего нет.
Так если прям надо во вьюхе отловить ошибку, то можно конкретно для этой вьюхи или декоратор прописать или контекстный менеджер атомарности транзакции указать. Не?
Немного оффтопный вопрос. Как используя ДРФ и JS-фронт работать с аутентификацией? Точнее, делать эндпоинты для получения себя, а в АПИ прокидывать уникальный идентификатор пользователя?
Огонь!
Спасибо!
Лайк через 6 секунд после публикации:)
Спасибо за видео, очень полезная информация! Но у меня дополнительный вопрос. Подобное поведение с неоткаченной транзакцией при отловленном в try/except исключении проявляется только если ATOMIC_REQUESTS активирован (True)? Или это вообще стандартное поведение при любом объявлении миграции, включая декоратор и with?
Только у меня создалось впечатление что в начале видео на столе стоит граненный стакан с водкой, а не водой?)
Великоват для водки:)!
@@t0digital возможно размер стакана пропорционален количеству проблем с проектом)))
Спасибо за видео. Получается, что Atomic requests стоит использовать не для всего проекта, а только для тех приложений (задач), в которых нужны транзакции? К примеру, биллинг.
Полезность 20 из 10
неовим?) Алексей, ждём видео!
Привет, большое спасибо за видео. Я хотел бы попросить вас поделиться вашей текущей конфигурацией vim.
Спасибо! Да, я хочу ещё донастроить и потом сделаю материал по настройке, сейчас линтер ругается в одном месте, где нет ошибок, хочу выяснить почему и как пофиксить
@@t0digital Я правильно заметил, что это neovim а не vim enhanced?
@@ashotvantsyan9028 nvim, yes
Не понял про последний вариант, там запись в БД вообще происходит(открывается транзакция СУБД) или нет, а откат как выполняется? Из кода на видео это не ясно. Такое чувство, что тут типа ленивого выполнения кода, т.е. сперва обе функции "как-бы" выполняются(без реальной записи в БД) и если все ОК, то оно выполнит запись в БД(создаст соотв-ие транзакции и т.п.).
Привет! Спасибо за видео. Вопрос не по теме: тебе хватает диагонали экрана твоего ноута, или хотел бы побольше (как у старого)?
Мне хватает, нормально, но это дело привычки/вкуса
Я думал в 2021 программисты стали недосягаемо круты, а оказалось, что зная ДОС и скрипты для онлайн игрушек можно за 10 минут въехать в тему...
Ан нет, мы досягаемо круты:)))
С drf тоже будет работать ?
Получается нужно избегать try except при запросах в orm или вообще во всех случаях?
а увеличиваеться ли счетчик при неудачной операции, точнее мне интересен механизм отката записей, каким образои он реализован?
если верно понял вопрос - транзакции СУБД отвечают за откат незафисированных, то есть незакоммиченных данных
Вот спасибочки!
Мне на секунду показалось, что это какой-то заключённый, который выстрелил
познавательно!
Здравствуйте!
Вопрос немного не по теме, хотел бы услышать ваше мнение. Работаю разработчиком БД, в работе используем Oracle, Teradata, Greenplum, Informatica(ETL). Опыт работы - 1 год. Знаю ДС на хорошем уровне(изначально им занимался, но предложили другую должность). Получаю в целом неплохо, 150+. Просто про базы данных всегда так вскользь упоминают, про ETL тоже особо не говорят. Как вы считаете, не стоит ли сменить направление, если говорить о перспективах и дальнейшей востребованности. Спасибо за ответ!
Привет! Спецы БД, ETL и тп зарабатывают нормально. Oracle, большие корпорации, нормально, если это ваше:) А вот если чувствуете, что это не ваше (неуютно себя чувствуете в корпорации или таких проектах для enterprise бизнеса), то можно подумать о переходе. Надо заниматься тем, что драйвит. Если текущее драйвит - отлично, если нет - ищите, что будет драйвить.
дай плиз конф nvim)
Блин, у Джанго в документации по транзакциям огромное примечание по обработке исключений
Полезная фича. Спасибо
Ни куя себе ты vim шумахер 😳. Круто 👍
интересное расследование, понравилось. хотя на питоне вообще не пишу )))
Видео очень доходчивое, классное, Но один Вопрос.... то что exception не возвращает статус 500 (а кидает 200) это так и надо или так можно ? )
Технически можно вернуть что угодно, конечно. 500ка это означает неожиданную ошибку сервера, если обрабатываемый сценарий именно такой, значит, стоит вернуть 500ку. Но фронтенд может ожидать всегда 200 или как-то не так обрабатывать 500ку, как вам нужно, такое тоже бывает, зависит и от фронтенда
@@t0digital Понял, спасибо Вам )
В чём сила, брат? В middleware!
Точно!
А почему rollback не использовать?
Ценное видео
Спасибо!
Агонь!!!!
Отправлять клиенту 500 ошибки такое себе решение. 500 ошибка - это ошибка сервера, а это значит, что если сервер падает на таком запросе, и такое поведение не ожидаемо, значит код работает неправильно. Для таких случаев нужно использовать Sentry, или что-то подобное, где разработчики могут сами видеть ошибки своих серверов. Если сентри использовать неохота, то этот middlware использовать для таких целей. Иначе, клиенту возвращать 4xx ошибки
Видос, зачëт! Вопрос глупый что делает функция __call__?
Еще есть вариант с транзакциями - это сессии SQLAlchemy, реализующие шаблоны Unit Of Work и Identity Map. Упрощенно так:
try:
u = Users(email=user_email, psw=hash)
db.session.add(u)
db.session.flush()
p = Profiles(name=user_name, user_id=u.id)
db.session.add(p)
db.session.commit()
except:
db.session.rollback()
А что на счёт транзакций с переключением базы данных? (Что то типа SAAS проекта) Допустим у нас есть одна база, назовём её main, где есть таблица с accounts/clients, и есть N других баз client_1, client_2, ..., это базы клиентов. Нам надо списать с одного нашего клиента деньги и записать другому нашему клиенту (соответственно в client_1/client_2/... есть одинаковые таблички, к примеру wallet). Ну и, допустим, у нас MySQL база. Как отработают транзакции в таком случае? Или, как это реализовать по-нормальному без того, что у тебя есть метод, который меняет коннекшин к базе? Вроде слышал одним ухом когда-то, как взрослые Senior-девелоперы говорили на перекуре, что в MySQL не поддерживается такая штука. Нельзя завернуть в транзакцию такое изменение, потому что при переключении коннекшина автоматически происходит коммит в БД, и получится что ты с одного снял, а другому не записал. ОК, если в этом принимает участие 2 базы, на это можно придумать костыль какой то, но если 10, тут уже по-сложнее будет. Очень хочу услышать какое то разумное объяснение что и как делать :) Спасибо
Транзакции же отлавливают в целом необработанный эксепшн. А базы это сторонние зависимости, к которым обращение идет через слой нашего кода. Соответственно, вне зависимости от этой зависимости, слой кода будет возвращать эксепшн при ошибке - соответственно сработает и обработка транзакций.
Если сказал дичь - не бейте палками, я фронтендер :)))
Немного не понял. То есть, это не транзакции баз данных? А транзакции именно в коде? Что то у меня не сошлось :) Я почему то думал, что оно оборачивает все запросы (запросы к БД, insert/delete/update/select), которые есть в методе в транзакцию БД
Это называется распределенная транзакция, транзакция, затрагивающая несколько независимых друг от друга систем. В целом очень сложная штука. В настоящее время есть два основных подхода, two phase commit и синхронизация на основе событий (event). В основном применяют event подход, он более гибкий и масштабируемый. Вкратце это работает так. В базе main создается таблица events. В одной транзакции вместе с изменением accounts добавляется запись в таблицу events в базе main. Далее есть процесс-координатор, который следит за таблицей events. При появлении там новой записи он блокирует эту запись и пытается сделать изменения в другой БД client_1/client_2, затем удаляет запись из таблицы events БД main, или меняет статус на обработанное. Сложность реализации координатора в том что во-первых он должен обрабатывать записи из таблицы events (тоесть менять из статус или удалять, в результате), а во-вторых, менять статус только тогда когда будет уверен что другая система, БД client_1/client_2 точно обработала запрос, поменяла у себя данные.
Примерно так. Минус в том, что данные отражаются в других системах client_1/client_2 не сразу, а с задержкой. Но от этого практически никуда не деться, лучше пока не придумали. Все с этим вынуждены мириться, с этой задержкой синхронизации баз данных.
Плюс в том что это масштабируется. Если 10 баз, запускается 10 координаторов, каждый работает со свой базой. И даже несмотря на то что они не будут синхронизированы одновременно, все равно, наступит момент, когда все они будут синхронизированы. Этот момент называют ещё eventual consistency
Оп-па! А я и не знал, что можно в конфиге для БД включить транзакции! У меня везде через менеджер контекста это реализовано. Можно немного оптимизироваться! ;-) Спасибо! ) А вот if request.path == ... в мидлвари, на мой взгляд, не очень хорошая идея. Этак она чрезмерно распухнуть может с кучей elif после if...
А зачем может понадобится под каждую вьюшку в проекте делать отдельный if в этой мидлваре? У меня нет идей. Есть, например, функционал платежей, он лежит в приложении payments, урлы начинаются с /payments, вот для них можно настроить мейлинг об отдельных ошибках админам, например
@@t0digital, только тут, скорее, под приложение (в джанговской терминологии), так-то у меня тоже нет идей. Я однажды попал в ситуацию, когда мидлварь оказалась "тяжелее" всех вьюх. Там от меня ничего не зависело, но с тех пор старательно минимизирую код в middleware, когда приходится их писать. ;-) Мэйлингом у меня логгер занимается, когда это необходимо, хэндлер с логлевелом critical... Единственный момент, где там можно выстрелить себе... хм-м... повыше колена - забыть raise после logger.critical(). Разве что сохранение трейсбэков (всех исключений) вынесено в мидлварь.
Смотрю я на это из точки Java,C# и у меня волосы седеют и активно шевелятся на голове. Чем дальше смотрю питон тем больше утверждаюсь что народ не оборачивает ORM своим далом, а про бизнес логика это что то из области фантастики.