IK
Вроде пашет
Size: a a a
2019 July 12
SM
ilya
потому что есть values(), values_list() для кверисета. Если надо по значениям пройтись - то выбери по вкусу
Спасибо, очень грамотная тема. вся история в две строки уложилась
i
Спасибо, очень грамотная тема. вся история в две строки уложилась
👍
AO
а если тестировать е2е без реально поднятого бэка, то при каждом пуске тестов нужно будет поднимать что-то что его заменит с такой же схемой/эндпоинтами. и при изменении бэка, править схемы на фронте, т.е. копипаста.
короче у меня это боль
короче у меня это боль
без бека быстрее, но я вовсе не говорю про это
AO
я говорю о том, что можно тестировать с бекендом, но не залезать в базу, а обходиться запросами GraphQL, например (нужны будут права доступа на всё для тестового юзера, но дополнительные методы API не нужны)
AO
то есть тестировать с бекендом - это не обязательно "проверять в базе", это "проверять, что API ответит"
AO
ведь API ты уже тестировал ранее и [поэтому] доверяешь
AO
вот, потому Behave опят таки был удобнее, покликал в интерфейсе, позаполнял формы, а потом прям джанговской ром проверил, что в базе всё, что нужно и как нужно ;(
мне кажется правильным продвигать вот этот подход, я на него часто ссылку кидаю https://github.com/phalt/django-api-domains
AO
в случае использования этого подхода, Django ORM будет только внутри services.py (ну, вероятно, в тестах ещё)
V💊
мне кажется правильным продвигать вот этот подход, я на него часто ссылку кидаю https://github.com/phalt/django-api-domains
он мне нравится, да, но почему это в твет на моё сообщения про тесты ? хД
AO
ты там написал про Django ORM, а этот подход, он практически полностью убирает потребность в Django ORM внутрь сервисов
AO
то есть Django ORM будет использоваться для тестов сервисов и в самих сервисах
AO
а за пределми этого всего - уже без неё
AO
это мне кажется тоже правильным потому что идёт сокращение зависимости именно от Django ORM, ты понимаешь, что вместо вот этого "да оно везде", это используется только в паре файлов
AO
и это даёт возможность поменять способ реализации API или сами сервисы переписать с Django ORM на, скажем, psycopg2 + SQL (ну, например, если цель - выделить микросервис и уже сразу без Django)
ZR
Есть модель города.
есть модель маршрута (город-город)
городов у меня 6.
хочу автозаполнить таблицу маршрутов, ловлю:RecursionError: maximum recursion depth exceeded while calling a Python object
есть модель маршрута (город-город)
городов у меня 6.
хочу автозаполнить таблицу маршрутов, ловлю:RecursionError: maximum recursion depth exceeded while calling a Python object
gg = Cities.objects.all()
for i in gg:
for k in gg:
qq = Route()
qq.city_from = i
qq.city_to = k
qq.save()
VB
Есть модель города.
есть модель маршрута (город-город)
городов у меня 6.
хочу автозаполнить таблицу маршрутов, ловлю:RecursionError: maximum recursion depth exceeded while calling a Python object
есть модель маршрута (город-город)
городов у меня 6.
хочу автозаполнить таблицу маршрутов, ловлю:RecursionError: maximum recursion depth exceeded while calling a Python object
gg = Cities.objects.all()
for i in gg:
for k in gg:
qq = Route()
qq.city_from = i
qq.city_to = k
qq.save()
Сильно глубоко в рекурсию уходит
VB
Непонятно почему в форме появились новые поля
ZR
Так а где тут рекурсия Cities.count() = 6
VB
Раньше там были только 3 поля загрузки и кнопка