сергей кузьмин, спасибо, я откорректировала формат значения в json. Попробовала указать type = map(any) или map(list(string)) - падает на fatalpanic: unknown validation type:6.
Да, речь о контроллерах (реконсайлерах). Что касается подов, для каждого сервиса создано по 2 пода в replicaset, один из которых обслуживает контроллеры сервиса, а второй вебхуки. В случае недоступности ведущего, второй подхватывает лидерство.
База данных - aws opensearch, для сервиса авторизации есть кэш (redis). Насчет очереди: насколько я знаю, все реконсайлеры используют очередь
На самом деле у меня нет особого права выбора)
Плюс загвоздка состоит в том, что для получения нового значения обновляемого параметра нужно по ходу дела делать разные запросы (в зависимости от вида аккаунта).
Saboteur, да, конечно: есть таблица аккаунтов. Их 2 вида, старый и новый. Нужно добавить столбик в таблицу для параметра А. Но для каждого вида аккаунта этот параметр запрашивается из разных источников.
То есть job должен бежать и смотреть, где в БД еще не обновлен параметр, потом определять вид аккаунта, делать соответствующий реквест и персист полученному значению.
Не совсем:
Есть сервис Х. В папке сервиса есть папка charts
Сервис X кроме всего прочего, должен загрузить ресурсы в определенном порядке.
Структура дерева сейчас:
Спасибо большое!
Но мой вопрос заключался, как построить порядок загрузки чартов (ресурсов): ну то есть, например, прописать, что pg-base (его темплейты) должен загрузиться только после того, как mq-app успешно загружен внутри моего приложения.
Если я верно понимаю этот пример, то приложение зависит от того, загружены ли остальные два.
То есть что чарты cr загрузятся только после того, как загружены их схемы (crds)
dodo512, спасибо вам огромное! Я в итоге сдалась и сделала замены через поиск индексов квадратных скобок и сабстринг, но regex выглядит гораздо элегантнее! Спасибо за помощь!!!
сергей кузьмин, спасибо, можно, пожалуйста, немного подробнее? Возможно, есть пример? На данный момент в е2е тестах (отдельный сервис) циклом вычитываются все lines с помощью BufferedReader.readLine(), на выходе получаем response, внутри которого только текст из body.
Хотя тестируемый сервис точно посылает хедеры.
Есть какой-то способ вычитывать вместе с хедерами?
сергей кузьмин, конечно, сначала всегда Гугл
Этот вариант я видела, и он не сработал, возвращает false.
Нашла вот такой вариант, что скажете? Тест проходит, но вопрос, грамотно ли это:
Let url = checkboxText.match(some regex for href)[1];
SpyOn(window, open");
Window.open(url, "_blank");
Expect(window.open).toHaveBeenCalledWith(url, "_blank");
Expect(url).toEqual("blabla");
По факту, я проверяю здесь больше не переход по ссылке, а тот факт, что из чекбокса получен ожидаемый url. Достаточно ли этого?
Да, спасибо, но если атрибут не в конце, и я ограничиваю его слешем, то вариант /account/tratata/{account}/tratata заменит мне первое вхождение account.
Там просто куча api будет в таблице, нереально писать под каждый отдельный реджекс.
Думала, может, как-то универсально можно
А можно ли, например, получая request, скопировать его, сделать ему setAtribute () для каждого атрибута и уже после этого вытаскивать из этой измененной копии uri (то есть уже готовый для сравнения стринг). Что скажете?
Dmitry Roo, вы имеете ввиду chainedTransactionalManager для этой ситуации?
Без spring boot, при условии если обе базы были бы в одном микросервисе, я бы написала три конфига (для одной бд со всеми бинами, включая менеджер транзакций), для второй, и для chainedTM), а в аннотации метода указала бы, какой менеджер использовать.
Но здесь речь о двух разных серверах, плюс как это делается в spring boot - я еще не сталкивалась
Я с вами абсолютно согласна. Однако, к сожалению, везде хотят человека-оркестра по системе полного цикла разработки. И кроме девопса, архитектора, фронтэндщика и бэкэндщика, оказывается, еще и бд надо уметь настроить со всех сторон)
Учитывая, что это серьезная фирма, а не молодой стартап, приходится рыть по всем фронтам.
Сергей Горностаев, спасибо, круто, но я должна где-то в конфиге это поставить на "on" - или подразумевается, что это автоматическая оптимизация со стороны бд?
Dmitry Roo, речь о бд, которая участвует в цепочке кросс-сервисного взаимодействия. То есть скорость обработки запроса от пользователя (например, поиск подборки информации по хитрому составному фильтру и отправка списка на фронт) получается в любом случае не молниеносная. Поэтому важно, чтобы поиск (например) в этой бд был организован максимально оптимально. Насчет построения быстрых запросов в бд (без кучи лупов и вложенных запросов) - это понятно.
Плюс хранится там будут важные коды, важна доступность: если упадет бд, слишком дорого обойдется. То есть как я понимаю, мне нужна система репликации: отправляю в мастер, данные копируются в слейвы. Если вдруг мастер упал, то его роль должна автоматом перейти к кому-то из слейвов (наверно, виднесс это отслеживает, если верно понимаю). Вопрос в том, что я ни разу не писала подобного кода и нуждаюсь в совете, как это принято делать.
Плюс масштабирование. Осуществляет ли postgresql разбивку на partitions динамически сама (наверно, нет), или как эту функцию явно включить, если я предполагаю, что бд может не справиться с потоком запросов.
В самом коде провайдера в схеме ресурса пишу:
"labels": {
Description: "blabla",
Type: schema.TypeMap,
Elem: &schema.Schema{
Type: schema.TypeList,
}
}
В чем может быть ошибка, на Ваш взгляд?