Свидетели Андрюшки

как в Даталоге ищут документы у которых значение одного из атрибутов входит в множество? А ля where id in (2,23,10)

Так вот, по поводу

test:
    $(shell exit 0)
ifeq ($(.SHELLSTATUS),0)
    $(error Some error message)
endif

не работает ¯\_(ツ)_/¯

Видимо что-то случилось

передаешь коллекцию айдишек в виде [?id ...], и на каждую айдишку получается проход

test:
    $(shell exit 0)
ifeq ($(.SHELLSTATUS),0)
    $(error Some error message)
endif

если я не ошибаюсь, то ifeq работает на этапе разбора файла, а не во время работы

Забавно, что в некоторых ситуациях SHELLSTATUS работает, а в некоторых - нет. Мне так и не удалось однозначно понять как оно работает и для чего оно нужно такое странное

Спасибо

Есть пет-проект с тестами клиентской части, в том числе и фетчей бэкенда по апи. Хочется надежно разделить, чтобы при тестах  на бэке использовалась тестовая база, а при работе - рабочая. Можно настроить отдельную пару конфигураций для тестового билда (и фронт и бэк), передавать туда параметр базы и запускать эти конфиги при тестах из командной строки. Но хочется совместить разработку и приложения и тестов, работая в одном запущенном конфиге. Сейчес добавил в апи эндпоинт, который тупо переключает базу бэка на тестовую и обратно, дергаю его в начале и конце тестов. Но как-то не нравится мне это. Думаю добавлять в хэдеры фетча специальный ключ, который будет означать запрос к тестовой базе. Но как удобнее управлять этим ключом, чтобы не переключать сборку? Пока только with-bindings приходит на ум, и оборачивать им все тесты. Но тоже можно забыть. Что посоветуете?

нормальный DI, как всегда 😉

а поподробнее можно? )

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

в частности чтобы разделить тестовые и дев окружения

то есть не щелкать базой в одном инстансе приложения а все-таки поднимать 2 одновременно и разруливать запросы к ним?

@prepor Сделать базу параметром, и какой-нибудь component для.

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

то есть вообще запускать 2 бэкенда и 2 фигвилла клиента на разных портах и жить так с динамическим обновлением обоих? прикольно )

А что это за тесты, которые не запускают всё им нужное сами?

надо только не перепутать в чей РЕПЛ выражения вычислять тогда