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

СИ научился конфликты решать?

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

Он тебе в ветку насильно впихивает мастер/дев если ты вафлишь

Так проблема не в том что я не вижу нового мастера, а в том что изменения в мастер 60% времени ломающие и ребейз превращается в 11 круг ада. И либо переходишь на мержи либо сливаешь все дерево в один коммит что кек, перед ребейзом

Опят же, проблема в головах. Если кто-то в мастер за раз выливает полгода работы за раз - шли нахуй

не всегда так можно

Опят же, проблема в головах. Если кто-то в мастер за раз выливает полгода работы за раз - шли нахуй

Так у нас проект то новый, тут это неизбежно

Я ненавижу мерж комиты

Хороший мержкоммит - пустой мержкоммит после пулл-реквеста в мастер.

Так проблема не в том что я не вижу нового мастера, а в том что изменения в мастер 60% времени ломающие и ребейз превращается в 11 круг ада. И либо переходишь на мержи либо сливаешь все дерево в один коммит что кек, перед ребейзом

Так у нас проект то новый, тут это неизбежно

Непустые мержи - это пиздец. У тебя сбои и косяки, начинаешь исследовать - косяк добавлен в мерж-коммите. И хер теперь знает, зачем то изменение в мерже было нужно

Надо стремиться

ребейз каждый день - ад, я делал раз в неделю

При атомарных коммитах даже серой не припахивает

Всегда есть исключения. Но я уверен что 99% проектов вполне могут работать на непрерывной интеграции, а аргументы против это обычно лень

коммит атомарен по определению. но у нас в процессе этих 8 месяцев ещё репу попилили пополам (отпилили FE от BE)

Поднять ТимСити может каждый.....

коммит атомарен по определению. но у нас в процессе этих 8 месяцев ещё репу попилили пополам (отпилили FE от BE)

Раздельное версионирование фронта и бека?

Как можно быстрее ебашить утилиты для тестов. Обычно эти разные апи работают не так как документировано и не так как тебе обещают

я бы помимо этого тянул их в общий топик в кафке без изменений

Гаспада, ожидается проектик где надо будет тянуть кучу всяких похожих сучностей из разных API, причесывать их, а потом по ним делать поиск/фильтрацию и etc. Вдруг кто, уже набитыми шишками, поделится?

У нас вот именно таких задач очень много. Щас опишу как она решена в одном проекте Есть сервис, который должен предоставлять ВСЕ данные какие возможно. Он потребляет все возможные кафки (а если инфа доступна только через апи, делают сервис, который поллит данные из апи и кладет в кафку) и складывает в единую сущность с примерно такой моделью: ids: { id1: optional id1 id2: optional id2 id3: optional id3 … }, datasource1: optional datasource1, datasource2: optional datasource2, … все датасорсы имеют свои айдишники, их надо как-то коррелировать, там могут быть разные отношения 1:1, 1:N, N:M это зависит Если там 1:M например, то внутри ids будет массив других айдишников. Как это наложить на твою БД и её индексы, зависит от БД. У нас в кассандре много таблиц маппинга, но какие-то бд умеют строить индексы по структуре Далее основной пейлоад имеет поля в которые тупо перезаписывается (или мержится) пришедшая инфа из datasource. Соответственно может вообще нихуя не придти, поэтому все поля опциональные. У всех должен быть таймштапм послднего ingestion У тебя может встать вопрос - а что если нужны поля, которые агрегируют несколько датасорсов? Тогда тебе нужно организовать change feed. Допустим в агрегации участвуют поля datasource1 и datasource2. Когда кто-то из них изменяется посылается событие в топик и отдельные сервис будет пересчитывать aggregatedField и перезаписывать его при получении новых данных. По итогу на каждое изменение полей (значимое) должно генериться событие в аутпут топик и консумеры должны получать инкременты изменений. АПИ поверх этого должно учитывать что пейлоад ебанистичеки большой и консумер может хотеть получать только его часть поэтому можно в квери писать имена полей из финального респонса, которые ты хочешь получить (соответственно из БД только их и грузить). Ты скажешь - ну это же графкуэль - я отвечу - ПОХОЖЕ, но моё мнение что графкуэль говна самовар.

почему тебе графкуль не нравится

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

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

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

в новом есть косты запросов, прямо на запрос или сущность вешаешь кост

в новом что? это же не графкуля фича, а каждой отдельной реализации

но в графкуле ты сам играешь в валидатора и сам играешь в планировщика

но комплексити запроса был ещё с бородатых времён

в 2017м чот не было

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

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

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

но ты то заранее знаешь откуда и что будешь запрашивать и насколько это больно будет

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

но ты то заранее знаешь откуда и что будешь запрашивать и насколько это больно будет

Ну это значит, что все пользователи должны быть профессионалами в построении быстрых запросов. Что для SQL оказалось не так.