А что если users, orders и вот это всё всегда крутится в dev контуре и доступно...
Тогда получаем, что тестируем мы не наши моки, а существующую систему - здесь и сейчас, ту систему которая через 3-4 дня окажется на проде. Даже Кафки свои в dev контуре. И при этом не важно кто и что запускает: локально поправленный users и его работу с gateway в dev или тестировщик интеграционные тесты на реальном приложении в dev контуре... Все работают с одной системой, а не с разными замоканными представлениями о системе
Добавьте ещё сказ про руководителей у которых паранойя, про сексуально озабоченных, про алкоголиков, ну и про тех которым бизнес купил папа но они ведь теперь ген директор
Начальник без здравого смысла - это прям зачин для сценария очередного фильма про чужих...
Правильно ли я понимаю что когда аппл выходил на рынок с моделью М1, то понимал, что продажи предыдущих моделей рухнут в кратчайшие сроки, соответственно делал это только имея или запас денег или запас макбуков уже с М1?
Почему в статье фигурирует понятие "язык"? Если примеры приведены без использования языка.
Пример с Германией и 2-й мировой, дети уже выросли и во взрослом состоянии имели в спящем виде "баг-исключительности", кто и когда заложил им этот баг, закладывает данный баг? Только про ветхий завет не нужно, книга эта локальная, а баг глобальный как я понимаю вас.
А какой аргумент тут может быть ещё? Есть работающая в течении 4х лет система, состоящая из множества независимых команд, обеспечивающая через этот паттерн платежи, сбоев связанных с тем, что фронты генерят UUID нет. Все по цепочке их передают и используют. Кто-то у себя этот UUID возможно НЕ использует как РК, а кто-то использует как PK в своей базе. Какой аргумент ещё нужен. Ни кто, риски привести не может...
А сама (одна заявка) входящая в пачку - сущность? И если да, то почему на этапе её жизни фронт-бэк-пачка-кафка-бэк у неё один идентификатор, а после её создания в базе - у неё уже появляется второй идентификатор... И все дружно психуют, что думают про конкретную заявку с id 654454, а другие ищут и думают про заявку 91122111, ой а третьи вообще воспользовалиcь id 55655 - который id пачки...
Вы такое готовы потащить к себе для rps 100 - пусть и не хайлоад, но уже нормально так... Мне вот неохота... Мне так и не объяснили, зачем, что-то такое тащить. Конкретно что такого, что создатель сущности и создаёт её id в формате UUID Она вполне может и не возникнуть, сущность эта, не добралась до базы и не возникла, отлично. Доберётся и возникнет в базе - вообще зашибись. Но, зато по пути она уже идентифицирована единообразно и уникально. У меня возникает иногда очучение, что у всех фронты (клиенты) просто напрямую с помощью SQL кода ходят в базу... и все тока и думают, как питонистов не пустить напрямую в базу.
Согласен, пачка заявок на переключение тарифов, точно отдельная сущность. Ну а одна заявка одного пользователя в первой пачке и потом эта заявка уже в следующей пачке ну конечно конкретная заявка этого пользователя возвращаемая в почке результатов - это всё три разные сущности. Ведь в базе сформирована "истинная" сущность 654445876 Остальные "мнимые". Истина она в базе. Саппорт идёт лесом, клиент туда-же вместе с мобилкой... К нам претензии есть - нет и быть не может, нам всё ИСБ согласовало, какие к нам могут быть претензии. Видите и запрос легко писать и работает он быстро... а в какой пачке и где потерялась ваша конкретная заявка, в какой кафке, на какой проксе - это не к нам, а к кому, да мы не в курсе - там где-то...
Ага, на каждом этапе свой id - это мечта саппорта и отладки фичи. А тут и нет оверинжиниринга, источник создают id и всё, проблем нет: ни с саппортом, ни с отладкой, ни с безопасностью, ни с перебором, ни с сортировкой v7 Вероятно есть проблема с привычкой
Статус обработки чего? id того чего статус нужно узнать кто создаёт? Я же показал, хоть пачкой хоть бочкой, кто выписал id? Ну и как я понимаю, при синхронных вы всегда сделаете автоикримент, но при асинхронных "как-то по другому" Получили два разных паттерна Может не стоит так и всегда делать удобно всем, а не базадистам... Это не выдуманная система, это просто распределённая, текущая, работающая уже года как 3 Её расширение не зависит от числа промежуточных узлов и необходимости анонимизации или шифрования данных на трансграничных переходах, и всяком таком прочем. А расчёт, что вот эта фича сейчас синхронная и останется синхронной - это закладывание себе самому переработок. Сегодня синхронная, а завтра - упс уже нет.
Понимаю, вы полагаете, что всё начинается с команды insert ну и на её ответе всё заканчивается. Как она на db попала - сие проблема не базадиста... У вас ведь всё за милисекунду - всё замечательно. фронт (узбекистан) - бэк узбекистан - синк_нод узбекистан - кафка - синк_хаб - мастер_бэк (проверки 5 секунд) - мастер база (микросекунда) - всё обратно... И если фронт генерит UUID то все службы вашего любимого саппорта и ваших нежных писателей запросов - ходят с одним и тем-же UUID и спрашиваю - а какого фига мы вам послали, а вы не ответили... аа у вас обслуживание ночью было... понятно
Хорошесть определяется не тем, что он молчит, а тем, что отличает лишнее от не лишнего.
Судя по всему у меня эту экологическую нишу занимает far2l
Если для вас начальник нужен чтобы отвечать по поводу и без: уволить, то понятно.
А что если users, orders и вот это всё всегда крутится в dev контуре и доступно...
Тогда получаем, что тестируем мы не наши моки, а существующую систему - здесь и сейчас, ту систему которая через 3-4 дня окажется на проде. Даже Кафки свои в dev контуре. И при этом не важно кто и что запускает: локально поправленный users и его работу с gateway в dev или тестировщик интеграционные тесты на реальном приложении в dev контуре... Все работают с одной системой, а не с разными замоканными представлениями о системе
Добавьте ещё сказ про руководителей у которых паранойя, про сексуально озабоченных, про алкоголиков, ну и про тех которым бизнес купил папа но они ведь теперь ген директор
Начальник без здравого смысла - это прям зачин для сценария очередного фильма про чужих...
Вроде нет, был и тем самым исполнителем и начальником отдела, никогда не был ген диром.
Сейчас в Энтерпрайзе.
Имхо, описанная ситуация не фактически существующая данность, а наше отношение и ощущение от нее.
Кроме того, статья ведь реклама - вон как у вас "хорошо", а кто-то умеет лучше...
Если каждый на своём месте делает ровно то, что ему поручено и ссылается на должностную инструкцию, то всё так и будет.
Если флаеры лягут в кладовку, то:
Зачем дизайнер трудится над тз? 5 минут и отправил.
Зачем большой бюджет, заказали 100 штук, типография без платёжки сделает. Станут проверять, скажу что это пробный был тираж, зайдет повторим...
И так далее, на каждом этапе. Просто делай то что нужно, а не то что сказали... Оно конечно подумать нужно... и не ошибиться слишком сильно...
Сочувствую, сталкиваться с таким не приходилось.
Правильно ли я понимаю что когда аппл выходил на рынок с моделью М1, то понимал, что продажи предыдущих моделей рухнут в кратчайшие сроки, соответственно делал это только имея или запас денег или запас макбуков уже с М1?
Почему в статье фигурирует понятие "язык"? Если примеры приведены без использования языка.
Пример с Германией и 2-й мировой, дети уже выросли и во взрослом состоянии имели в спящем виде "баг-исключительности", кто и когда заложил им этот баг, закладывает данный баг? Только про ветхий завет не нужно, книга эта локальная, а баг глобальный как я понимаю вас.
А какой аргумент тут может быть ещё?
Есть работающая в течении 4х лет система, состоящая из множества независимых команд, обеспечивающая через этот паттерн платежи, сбоев связанных с тем, что фронты генерят UUID нет. Все по цепочке их передают и используют. Кто-то у себя этот UUID возможно НЕ использует как РК, а кто-то использует как PK в своей базе.
Какой аргумент ещё нужен.
Ни кто, риски привести не может...
А сама (одна заявка) входящая в пачку - сущность?
И если да, то почему на этапе её жизни фронт-бэк-пачка-кафка-бэк у неё один идентификатор, а после её создания в базе - у неё уже появляется второй идентификатор...
И все дружно психуют, что думают про конкретную заявку с id 654454, а другие ищут и думают про заявку 91122111, ой а третьи вообще воспользовалиcь id 55655 - который id пачки...
Вот. Ключевое!
Если первичный ключ UUID v7 то я действительно не вижу абсолютно ни каких рисков в его создании на фронте.
А прибыток вижу.
Вы такое готовы потащить к себе для rps 100 - пусть и не хайлоад, но уже нормально так...
Мне вот неохота...
Мне так и не объяснили, зачем, что-то такое тащить.
Конкретно что такого, что создатель сущности и создаёт её id в формате UUID
Она вполне может и не возникнуть, сущность эта, не добралась до базы и не возникла, отлично. Доберётся и возникнет в базе - вообще зашибись.
Но, зато по пути она уже идентифицирована единообразно и уникально.
У меня возникает иногда очучение, что у всех фронты (клиенты) просто напрямую с помощью SQL кода ходят в базу... и все тока и думают, как питонистов не пустить напрямую в базу.
Согласен, пачка заявок на переключение тарифов, точно отдельная сущность. Ну а одна заявка одного пользователя в первой пачке и потом эта заявка уже в следующей пачке ну конечно конкретная заявка этого пользователя возвращаемая в почке результатов - это всё три разные сущности.
Ведь в базе сформирована "истинная" сущность 654445876
Остальные "мнимые".
Истина она в базе. Саппорт идёт лесом, клиент туда-же вместе с мобилкой...
К нам претензии есть - нет и быть не может, нам всё ИСБ согласовало, какие к нам могут быть претензии.
Видите и запрос легко писать и работает он быстро... а в какой пачке и где потерялась ваша конкретная заявка, в какой кафке, на какой проксе - это не к нам, а к кому, да мы не в курсе - там где-то...
Ага, на каждом этапе свой id - это мечта саппорта и отладки фичи.
А тут и нет оверинжиниринга, источник создают id и всё, проблем нет: ни с саппортом, ни с отладкой, ни с безопасностью, ни с перебором, ни с сортировкой v7
Вероятно есть проблема с привычкой
Ну да, человекоНЕчитаем, сложно писать запросы.
Я понял, это да, это причина...
Зачем что-то брать чужое.
Просто тот кто инициирует, тот и создаёт id (в формате UUID v7)
Всё! Что не так?
Статус обработки чего? id того чего статус нужно узнать кто создаёт?
Я же показал, хоть пачкой хоть бочкой, кто выписал id?
Ну и как я понимаю, при синхронных вы всегда сделаете автоикримент, но при асинхронных "как-то по другому"
Получили два разных паттерна
Может не стоит так и всегда делать удобно всем, а не базадистам...
Это не выдуманная система, это просто распределённая, текущая, работающая уже года как 3
Её расширение не зависит от числа промежуточных узлов и необходимости анонимизации или шифрования данных на трансграничных переходах, и всяком таком прочем.
А расчёт, что вот эта фича сейчас синхронная и останется синхронной - это закладывание себе самому переработок. Сегодня синхронная, а завтра - упс уже нет.
Понимаю, вы полагаете, что всё начинается с команды insert ну и на её ответе всё заканчивается. Как она на db попала - сие проблема не базадиста... У вас ведь всё за милисекунду - всё замечательно.
фронт (узбекистан) - бэк узбекистан - синк_нод узбекистан - кафка - синк_хаб - мастер_бэк (проверки 5 секунд) - мастер база (микросекунда) - всё обратно...
И если фронт генерит UUID то все службы вашего любимого саппорта и ваших нежных писателей запросов - ходят с одним и тем-же UUID и спрашиваю - а какого фига мы вам послали, а вы не ответили... аа у вас обслуживание ночью было... понятно
Отлично, и как мы с автоикриментом в базе построим асинхронную систему?