Я как ни попытаюсь к ней подойти - возникают мысли "а почему это так?"

Потому что ты не начинающий

Мужики, давайте без очередной заезженой дискуссии. Что толку то?

а во фласке все довольно тупо и очевидно

Я тоже за фласк

И у тебя какая-то модель в голове уже есть

а во фласке все довольно тупо и очевидно

да там везде все очевидно и во фласке и в джанге. Джанга - коробка "все свое ношу с собой", фласк "собери сам" вот и вся разница

я согласен с первым утверждением. если на 100% известно что бекенд ни для чего кроме апи использоваться не будет, то можно и Фласк\Фалькон Но обычно и ОРМ и админка и авторизация какая-нибудь нужна. В случае фласка придется прикручивать еще компоненты, а в джанго есть изкаропки

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

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

Всмысле связаны?

в смысле юзают базу

Я как ни попытаюсь к ней подойти - возникают мысли "а почему это так?"

это твой крест, как умного человека)

обычные люди просто принимают как данность и работают с тем что есть)

Ну, у меня не юзают, что я делаю не так?)

я сам не писал на джанге, но чет куда ни гляну у всех "юнит" тесты юзают базу

я согласен с первым утверждением. если на 100% известно что бекенд ни для чего кроме апи использоваться не будет, то можно и Фласк\Фалькон Но обычно и ОРМ и админка и авторизация какая-нибудь нужна. В случае фласка придется прикручивать еще компоненты, а в джанго есть изкаропки

import flask-sqlalchemy? батарейки для авторизации тоже есть

я помню в рельсах тоже использовалась отдельная база которая заполнялась тестоввыми данными и очищалась по окончанию тестов

Ну, у меня не юзают, что я делаю не так?)

видимо ты как раз делаешь все как надо

я сам не писал на джанге, но чет куда ни гляну у всех "юнит" тесты юзают базу

Да не обязательно. Можно не использовать. Но при прогонке тестов поднимается временная тестовая БД, можно ее заполнить тестовыми данными, которые умрут вместе с БД после завершения

Сделаем легче: кто начинал с джанго или фласк и был доволен первым выбором

видимо ты как раз делаешь все как надо

а как надо?)))) Я сильно сомневаюсь всегда в существовании одного верного решения.

Да не обязательно. Можно не использовать. Но при прогонке тестов поднимается временная тестовая БД, можно ее заполнить тестовыми данными, которые умрут вместе с БД после завершения

эм. это уже не юнит тесты, елси они лазят в БД

это уже полуинтеграционные какие-то

эм. это уже не юнит тесты, елси они лазят в БД

Это уже вопросы терминологии и философии.

ну вот для тестов бизнеслогики не нужна БД, нужно тестить только бизнес логику.

а работу с БД можно прерить отдельно

ну вот для тестов бизнеслогики не нужна БД, нужно тестить только бизнес логику.

Значит, не надо ее использовать) Никто не запрещает

использование БД усложняет тест

1. ты не можешь некоторые кейсы воспроизвести, потому что хз как их на текущую реализацитю БД натащить 2. тесты начинают пересекаться по данным и мешать друг другу. В идеале пересоздавать БД перед каждым тестом, но тогда пункт 3 становится ещё хуже 3. Тесты с БД сильно медленнее

ну да ладно

в общем, джанга предлагает набор методик, которые зачастую вредные или спорные и в перспективе как раз дают меньше гибкости приложению

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

"от задачи зависит", ой, как же меня бесит эта хуйня. - Можно ли ебать детей? - От задачи зависит.

но в 90% случаев это и не нужно для тех сайтов, которые делают

1. ты не можешь некоторые кейсы воспроизвести, потому что хз как их на текущую реализацитю БД натащить 2. тесты начинают пересекаться по данным и мешать друг другу. В идеале пересоздавать БД перед каждым тестом, но тогда пункт 3 становится ещё хуже 3. Тесты с БД сильно медленнее

- Да, БД пересоздается каждый раз. Чаще всего. Это если используется - Чтобы не пересекались по данным надо подчищать после теста за собой. Либо терпеть пересечения. - Да, медленней, потому что с БД.

каждый раз - перед каждым тестом

это единственный более менее работающий способ очистки

и то не факт, мы как-то написали тест, который просто сломал схему БД и она даже не удалялась

yj 'nj rjytxyj cjdctv rhfqybq ckexfq

но это конечно крайний случай

"от задачи зависит", ой, как же меня бесит эта хуйня. - Можно ли ебать детей? - От задачи зависит.

приведённый вами пример как-о опровергает фразу "От задачи зависит." ?

А во ткак чистить схему после провалившегося теста - непонятно, потому что тест провалился и значит поведение неопределено.

Я новичок в бэкенде. Знаю js и python. Сейчас решаю задачки на leetcode. Вопрос таков. Какой фреймворк изучить для бэкенд? Я знаю mongoDB и буду писать в основном Rest API. Ответы пожалуйста с аргументами. Спасибо

sanic! Или FastAPI )

приведённый вами пример как-о опровергает фразу "От задачи зависит." ?

Он показывает абсурдность такого утвержения

"от задачи зависит", ой, как же меня бесит эта хуйня. - Можно ли ебать детей? - От задачи зависит.

Вас не учили культурно разговаривать? Не все готовы поддерживать диалог в таком ключе.

Он показывает абсурдность такого утвержения

эээм нет не показывает

sanic! Или FastAPI )

Саник прикольно, но надо будет прикручивать орм туда. Потому что гино – помойка.

А во ткак чистить схему после провалившегося теста - непонятно, потому что тест провалился и значит поведение неопределено.

эм ... как можно поломать схему в тесте, если обычно тест запускается в одной транзакции?

sqlalchemy-core и никаких orm)

А во ткак чистить схему после провалившегося теста - непонятно, потому что тест провалился и значит поведение неопределено.

А зачем? Если он свалился, то надо его починить и перезапустить тесты. Ведь последующие уже будут сломаны тоже.

Есть вроде еще peewee-async

эм ... как можно поломать схему в тесте, если обычно тест запускается в одной транзакции?

например тест миграций =D

А зачем? Если он свалился, то надо его починить и перезапустить тесты. Ведь последующие уже будут сломаны тоже.

елси сломался тест, хочется видеть какой конкретно сломался. И вдеть что остальные не сломались.

sqlalchemy-core и никаких orm)

Сложно

например тест миграций =D

Ммм, тесты миграций. Помимо вопроса "зачем", мне кажется, что такие штуки тестятся прямо на дев/стейдж сервере через CI

Иначе можно чинить 1000 тестов, хотя сломались 100 только

Сложно

Ну не знаю, мне вот нормальные запросы на django-orm куда сложнее строить)

елси сломался тест, хочется видеть какой конкретно сломался. И вдеть что остальные не сломались.

можно запускать —failfast, на первом упавшем останавливаешь

Кто нибудь получал фото учетной записи из AD через LDAP ?

Вас не учили культурно разговаривать? Не все готовы поддерживать диалог в таком ключе.

Да окей. Сути не меняет

Ммм, тесты миграций. Помимо вопроса "зачем", мне кажется, что такие штуки тестятся прямо на дев/стейдж сервере через CI

ну ладно. Про миграции скорее шутка. Но вот как ты будешь тестить в одной транзакции тот код, который уже юзает несколько транзакций - хз

Если мы говорим про веб-приложение, если у вас код юзает несколько транзакций - это уже больно

эм ... как можно поломать схему в тесте, если обычно тест запускается в одной транзакции?

нуну, в любой момент времени в любом месте может появится сайдэфект который может что-то и закоммитить спокойно

Фласк или Джанго? Вроде та же херня только в профиль, а вот если открыть вакансии, то джанго-джанго-джанго

Если вы коммитите ручками, при условии, что вы используете Django, то эти ручки лучше исправить. Реально не могу представить случая, зачем коммитить в обход django

Фласк или Джанго? Вроде та же херня только в профиль, а вот если открыть вакансии, то джанго-джанго-джанго

Хз Я не зная Джанго найду работу на Джанго, если приспичит

ну ладно. Про миграции скорее шутка. Но вот как ты будешь тестить в одной транзакции тот код, который уже юзает несколько транзакций - хз

Еще добавлю, что несколько транзакции могут быть нужны исключительно для синхронизации данных между несколькими процессами, по идее. А в случае одного теста это вполне можно выполнить в одной, что django и делает

Хз Я не зная Джанго найду работу на Джанго, если приспичит

Ошибка выжившего? Окей

Фласк или Джанго? Вроде та же херня только в профиль, а вот если открыть вакансии, то джанго-джанго-джанго

Это рынок. И разработчики идут за рынком. Можно сколько угодно твердить про фласк, ботл и другие вещи, но если на рынке это не нужно, то толку от них 0

Еще добавлю, что несколько транзакции могут быть нужны исключительно для синхронизации данных между несколькими процессами, по идее. А в случае одного теста это вполне можно выполнить в одной, что django и делает

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

и дать юзеру возможность перезалить вторую половину

Опять же, в случае теста это все может выполнятся в одной транзакции, разве нет?

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

Это рынок. И разработчики идут за рынком. Можно сколько угодно твердить про фласк, ботл и другие вещи, но если на рынке это не нужно, то толку от них 0

Ага. Рыночек решает. Но я бы в столь категоричной форме не высказывался - фласк тоже есть на рыночке. Просто его намного меньше.

кстати, а что значит "знаю фласк"?

основы, который за день понимаются, или уметь искать батарейки, которые гуглятся за минуту?

основы, который за день понимаются, или уметь искать батарейки, которые гуглятся за минуту?

+

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

Ну так оно так и сохранится, если вторая часть упадет, потому что отката транзакции не будет

еще интереснее про "знать bottle", который вообще однофайловые фреймворк

Ага. Рыночек решает. Но я бы в столь категоричной форме не высказывался - фласк тоже есть на рыночке. Просто его намного меньше.

Я говорю о любой технологии, а не только про фреймворки

другое дело, что надо уметь в http(s), понимать как работают миграции, как работает окружение (от сервера до БД). и вот тут новичку будет полезнее по одной батарейке подключать и смотреть, чем в джанге запустить проект и долго смотреть на него, имхо

другое дело, что надо уметь в http(s), понимать как работают миграции, как работает окружение (от сервера до БД). и вот тут новичку будет полезнее по одной батарейке подключать и смотреть, чем в джанге запустить проект и долго смотреть на него, имхо

Что за батарейки?

Что за батарейки?

доп либы, которые дают то, чего нет во фласке изначально

кеширование, орм, ...

можно в pypi посмотреть на список по запросу flask-*

можно в pypi посмотреть на список по запросу flask-*

а в питоне встречается ситуация, когда есть несколько модулей от разных авторов, которые делают _примерно_ то же самое?

да полно

а в питоне встречается ситуация, когда есть несколько модулей от разных авторов, которые делают _примерно_ то же самое?

Ээ нууу да

Как и везде где больше одного издателя модулей

(Мы тут кстати сейчас обсуждали фласк и джанго, которые _примерно_ одно и то же делают)

Кто-нибудь встречал либы для работы с json полями в mysql/mariadb?

(Мы тут кстати сейчас обсуждали фласк и джанго, которые _примерно_ одно и то же делают)

не совсем. джанго может делать тоже самое что и фласк, но голый фласк не может делать того что может голый джанго(фреймворк).

я в жс устал тратить кучу энергии на выбор модулей для приложения поэтому, мне проще взять Джанго которая покрывает 90% типовых потребностей и не ломать голову над тем что выбрать для ОРМа и что для темплейтов.

я в жс устал тратить кучу энергии на выбор модулей для приложения поэтому, мне проще взять Джанго которая покрывает 90% типовых потребностей и не ломать голову над тем что выбрать для ОРМа и что для темплейтов.

ну, вроде программным инженерам за это и платят, чтоб те выбирали инструменты под задачу и пользовались ими, но это не точно

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

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

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

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

+