нейрослоп я сам не люблю, потому что это просто набор символов без цели. у меня же есть техническая база и определенные цели. я приглашаю аргументированно к дискуссии и задавать вопросы на github.com/redbase-app
я боюсь что я буду писать это достаточно долго, и не очень продуктивно. и потому в свет либо она никогда не выйдет, либо через пару лет, и к тому же мне за это не платят. а в наш век нейронок наверное надо использовать этот инструмент, оно экономит кучу времени. и самое главное, я всеже читаю что у меня получилось, перед тем как публиковать, потому как у нейронок большая и больная фантазия.. пока по крайней мере.
не, ну можно конечно и с самим собой поговорить. тут ведь как, статья помечена - сложно. я уже не однократно писал что не копирайтер. шлифует да нейронка. так как из меня так себе писатель. я пытаюсь донести основную мысль.
откуда взялась статья, сегодня с коллегой обсуждали SSO в компании, и проговаривали что и где может продырявится.... и вот как результат беседы я выложил на нейронку чтоб отразило ровненько мои мысли.
однако прошу заметить тут не нейрослоп. а вполне можно зайти и посмотреть исходники и уже аргументированно критиковать.
По второму пункту вы правы, и это была ошибка в мою пользу. Строку про заметность я написал задом наперёд: украденный токен идёт с чужого IP, чужого user-agent и чужой геолокации, то есть аномалией ловится лучше. А XSS в браузере жертвы приходит с её собственного адреса, в её рабочие часы, и поведенчески почти неотличим от неё самой, то есть ловится хуже. Симметричный аргумент «другой IP» я применил только там, где он мне выгоден, и не применил там, где он играет против.
Хуже того, фраза «ловится поведенчески» противоречит моему же разделу ниже, где написано, что детектора аномалий у нас пока нет. Приписал себе механизм, отсутствие которого сам же и признал.
Таблицу переписал: теперь по заметности BFF проигрывает. Он выигрывает четыре строки из пяти, а не пять из пяти, и так гораздо ближе к правде, хотя в реале всёж BFF как не крути лучше.
Про CSRF согласен, в статье он мелькал в скобках, хотя заслуживает отдельного места. Смысл ровно ваш: переход на куки не убирает риск, а меняет его форму. У нас стоят обе линии, SameSite=Lax плюс Secure и HttpOnly на куках, и поверх app.UseAntiforgery() с токеном в каждой изменяющей форме. Именно вместе, потому что SameSite не спасает от атаки с собственного поддомена и отваливается, если какому-то потоку понадобился SameSite=None. Вынес в отдельный подраздел.
Нет конечно, это будет по типу оверинж: в статье этого не было, а надо было. BFF это браузерный паттерн, натив в него не укладывается, и встроенный веб-вью ради него был бы прямым нарушением RFC 8252, который требует системный браузер.
Для натива работает другая связка: системный браузер плюс PKCE для авторизации, хранилище ключей ОС (Keychain, Keystore) для токенов, и DPoP как основная защита. У DPoP приватный ключ генерируется в защищённом хранилище устройства и оттуда не извлекается, поэтому украденный из приложения токен без него бесполезен. Это второй слой из статьи, и для мобильных он несёт основную нагрузку, а не BFF.
Если формулировать одной фразой: BFF решает задачу для браузера, DPoP для всего остального. У браузера есть куда спрятать токен на сервере, у мобильного приложения нет, поэтому там защищают не хранение, а применение. Добавил в статью отдельный подраздел.
Вы правы, и попали ровно в место, где это так. В Tsak троттл API-ключей берёт parts[^1] из XFF без списка доверенных прокси, модель однохоповая. В changelog 3.7.0 это допущение записано словами «assumes exactly one trusted proxy», а в статью оговорка не доехала. При цепочке Anti-DDoS → nginx правый хоп это адрес шлюза, и все за ним делят одну корзину. Причём это хуже, чем блокировка всех: правило «успешный вход обнуляет счётчик» в общей корзине сбрасывает счётчик и атакующему.
Ваш рецепт правильный, и он у нас уже есть, только в соседнем продукте: TrustedProxyResolverProcessor в redb.Identity делает KnownProxies/KnownNetworks, проверяет сокетный пир и идёт справа налево до первого недоверенного адреса. Tsak на эту модель переведём, единственная поправка к рецепту: нераспознаваемый хоп должен обрывать обход, а не пропускаться, иначе обход уедет в клиентскую часть заголовка. Статью поправлю, чтобы правый хоп не звучал как безусловное свойство. Спасибо, замечание нашло расхождение между двумя реализациями, а не опечатку.
Согласен, мне надо конечно внимательней надо быть.
Справедливо для гринфилда без ограничений. Но в банках речь не о выборе SOAP заново для нового сервиса вся парадигма вокруг уже построена: существующие потребители, ESB, регламенты аудита безопасности, мониторинг всё это годами живёт на SOAP/WS-*. Новый сервис внутри такой среды говорит на том же протоколе не потому что кто-то ностальгирует, а потому что сменить саму парадигму решение уровня всей организации, а не отдельной команды. Это больше похоже на "огромный багаж, на который оглядываешься", чем на архитектурный выбор здесь и сейчас.
тут как бы не попрёш против того что прописано и руководство просто не даст тебе внедрить новые протоколы верхнего уровня, Написано так и живём. 🤷♂️
Понимаю боль, RethinkDB был крутой техникой без бизнес-модели, обидная история. У меня хотя бы буква "base" сзади, а не "think" 😄
но ситуация другая: RethinkDB была самой базой - умерла инфраструктура. У меня данные в обычных таблицах Postgres/MSSQL/SQLite, с честными FK, если redb завтра исчезнет, ваши данные никуда не денутся, их и руками через SQL прочитать можно. Не увозим данные с собой, если что. Исходники тоже на месте.
Отличная подборка, спасибо! Заметил, что все десять концепций про организационную сторону (кто решает, когда стартовать/останавливать, как оценивать). А есть, по-моему, не менее фундаментальный пробел с инженерной стороны, который редко формулируют явно:
У системы почти всегда есть несколько валидных точек старта, и то, с какой начать, определяет фундамент, а не просто стартовую скорость. Можно начать с модели данных получится data-centric система. Можно с интеграционных контрактов message-centric. Можно с периметра безопасности более жёсткая и осторожная с рождения. Это не вопрос "стартовать раньше/позже" (как в вашем Stage Zero), а вопрос "с чего именно стартовать", когда решение строить уже принято.
И рядом с этим - архитектура, понятная разработчикам, а не просто работающая. Ни governance, ни NoEstimates, ни антихрупкость ничего не говорят о том, поймёт ли человек, пришедший через полгода, что вообще происходит в системе а это, кажется, минимум такая же по весу переменная, как всё перечисленное.
Справедливое замечание, и вы правы — Amadeus Ticket Changer действительно давно и хорошо автоматизирует пересчёт тарифа при voluntary/involuntary reissue (Category 31/33 ATPCO), это решённая задача, когда весь билет виден одному GDS. Не спорю с этим.
На практике мы так и делали: сначала смотрели, что предлагает каждый GDS сам по себе — это уже оптимальные, провалидированные через-тарифом связки, и в первую очередь оценивали именно их. А варианты из разных источников (self-connect) собирали и сравнивали уже отдельно, вторым шагом, как альтернативу — иногда через-тариф от одного GDS оказывается выгоднее, иногда комбинация из разных источников дешевле, и дальше вопрос уже в том, что важнее заказчику: гарантированная стыковка одним источником или экономия ценой риска и неудобства на пересадке.
Проблема, которую я описываю, начинается именно на этом втором шаге — там, где ATC сам предупреждает о своей границе: "tickets issued through other GDSs... are not guaranteed" Amadeus Fare Guarantee. Речь не о смене маршрута внутри одного билета, а о ситуации, когда решили, что self-connect выгоднее, и маршрут собран из трёх разных источников — три независимых билета, ни один GDS не видит два других. Замена одного плеча в такой конструкции — это не reissue внутри PNR, а согласование между источниками, которые друг о друге не знают. Ни один из GDS эту часть не решает и не может — у них просто нет данных о существовании билетов из соседних систем.
Спасибо за наводку — стоит явно назвать ATC и очертить эту границу в тексте, чтобы не создавалось впечатление, что я не в курсе существующих инструментов.
вообще интересная тема и решил покопаться, в помощь взял нейроку, и вот что вышло ____
Копнул — статья смешивает подтверждённые факты с довольно шаткой причинно-следственной теорией, и есть конкретная нестыковка по датам, которая рушит центральный тезис автора.
Что подтверждается независимо:
Водяной знак — реальный, задокументирован Fortune, TechTimes, Reuters-уровня источниками: с 2 августа 2026, статистическая метка на уровне модели (не невидимые символы), под требования Article 50 EU AI Act, применяется глобально, не только в ЕС. Это не выдумка блогера.
Opus 5 — реальная модель, вышла 24 июля 2026 (это позже, кстати, чем модели из моего собственного системного промпта — то есть для меня это тоже новость постфактум).
Жалобы на многословность и потерю смысла в Opus 5 — тоже реальные, задокументированы независимо (разбор MindStudio, тред на Hacker News, официальный GitHub issue в репозитории claude-code с конкретными измерениями).
А вот тут центральная теория автора (водяной знак → деградация Opus 5) рушится по датам. Жалобы на многословность Opus 5 фиксировались до 2 августа — материал MindStudio датирован примерно 1 августа, тред на HN старше двух недель на момент этой статьи. То есть модель уже жаловались как на "многословную и запутанную" раньше, чем вообще включили водяной знак — значит знак физически не может быть причиной того, что уже существовало до него. При этом в самом GitHub issue есть официальный анонс постмортема Anthropic с конкретными, раскрытыми причинами прошлых просадок качества (баг с уровнем effort, баг с историей размышлений, неудачное системное изменение под многословность) — то есть паттерн "нашли баг → объяснили → откатили" у них уже был, не "молчат и скрывают".
Про "уже вводили в заблуждение насчёт военного использования" — это не бьётся с тем, что реально задокументировано. По многочисленным источникам (CNN, Reuters, Al Jazeera) картина обратная: Anthropic публично и настойчиво отказывалась от неограниченного военного использования (автономное целеуказание, слежка за гражданами США), из-за чего Пентагон демонстративно понизил их статус, а компания в ответ подала в суд на правительство. Это не "скрывали военное использование", а ровно наоборот — публичный, судебный конфликт из-за того, что они слишком жёстко ограничивают именно такое использование. Автор этот пассаж явно не проверял.
Сама статья честно помечена автором как "Мнение" и "моя версия... возможно лишь частично верна" — то есть жанр разрешает спекуляцию. Но конкретно эти два места (причинность с водяным знаком и намёк на скрытое военное применение) не выдерживают проверки по датам и источникам, а не просто "спорное мнение".
Оба выловили не тестами, а на живом приложении: строили на этом же стеке своё — телеграм-бот через redb.Route.Telegram как фронт, а за ним LLM-часть, работающая с оперативными данными. Там и вылезло.
Тесты были — и в этом самое интересное. Они не покрыли эти кейсы, потому что писал их я же и ровно под тот способ использования, который держал в голове. У API несколько равноправных путей, а покрыт оказался мой.
Пример прямо из этого релиза: URI эндпоинтов я всегда писал строкой, а не fluent-строителем. Поэтому расхождение кодека строителя с парсером — значения с пробелами не переживали круговой обход — у меня физически не могло воспроизвестись: этой ветки в моём коде не было. Тест «маршрут работает» проходил, потому что проверял мой путь.
С деревьями последствия серьёзнее. WhereLeaves() замещал корневой CTE вместо того, чтобы быть предикатом поверх него, то есть запрос молча означал «свежайший лист схемы во всей базе». Ошибки нет, ответ правдоподобный — просто не про того. На одном собеседнике это невидимо в принципе; в боте со вторым пользователем видно сразу — человеку приезжает чужая история.
Сейчас оба пути закрыты тестами, фикс дерева ушёл во все шесть провайдерных комбинаций и в нативное расширение SQLite.
Могу тока добавить, что рассчитать стоимость по тарифной сетке, публичные и внутренние цены, плюс система скидок, тоже не простая задача, и связать всё это с 1С.
Понял, спасибо за ссылку — интересный подход с CRDT, особенно семантическая гранулярность вместо посимвольной. Хотя тут немного другая задача: redb.SQLite — это типизированное хранилище с SQL запросами и схемой, а outbox в статье — сознательно простой конфликт-хендлинг под контролем приложения. CRDT-синк — это скорее слой ниже/сбоку, не альтернатива типизированному стору. Возьму на заметку, спасибо.
Спасибо! А что вы имели в виду под "гипер базой" — можете уточнить? Тут в статье клиентское хранилище (SQLite прямо в приложении/браузере, без сервера), не совсем понимаю, в какой момент она бы пригодилась.
статья про клиентское хранилище: SQLite встроен прямо в приложение (на телефоне) или в браузер, без сервера вообще. HyperBase — это managed-хостинг для серверного Postgres, он для другого сценария (там, где redb.Postgres/redb.MSSql). Если интересно — у меня есть статьи и про серверную часть, там как раз к месту.
спасибо за уточнение — DETACH PARTITION перед DROP корректнее на нагруженных таблицах. Основная тема статьи — планировщик, пример очистки был иллюстративным.
@lazarus_net гоняю тесты с нейронкой, и я забыл вогнать поля, да и не было нужды в них, но тест дал варнинг, нейронка увидела и добавили и вот что пишет сама
нейрослоп я сам не люблю, потому что это просто набор символов без цели.
у меня же есть техническая база и определенные цели.
я приглашаю аргументированно к дискуссии и задавать вопросы на github.com/redbase-app
там нет статей, всё очень конкретно и точечно.
я боюсь что я буду писать это достаточно долго, и не очень продуктивно. и потому в свет либо она никогда не выйдет, либо через пару лет, и к тому же мне за это не платят.
а в наш век нейронок наверное надо использовать этот инструмент, оно экономит кучу времени.
и самое главное, я всеже читаю что у меня получилось, перед тем как публиковать, потому как у нейронок большая и больная фантазия.. пока по крайней мере.
не, ну можно конечно и с самим собой поговорить.
тут ведь как, статья помечена - сложно.
я уже не однократно писал что не копирайтер.
шлифует да нейронка. так как из меня так себе писатель.
я пытаюсь донести основную мысль.
откуда взялась статья, сегодня с коллегой обсуждали SSO в компании,
и проговаривали что и где может продырявится....
и вот как результат беседы я выложил на нейронку чтоб отразило ровненько мои мысли.
однако прошу заметить тут не нейрослоп. а вполне можно зайти и посмотреть исходники и уже аргументированно критиковать.
По второму пункту вы правы, и это была ошибка в мою пользу. Строку про заметность я написал задом наперёд: украденный токен идёт с чужого IP, чужого user-agent и чужой геолокации, то есть аномалией ловится лучше. А XSS в браузере жертвы приходит с её собственного адреса, в её рабочие часы, и поведенчески почти неотличим от неё самой, то есть ловится хуже. Симметричный аргумент «другой IP» я применил только там, где он мне выгоден, и не применил там, где он играет против.
Хуже того, фраза «ловится поведенчески» противоречит моему же разделу ниже, где написано, что детектора аномалий у нас пока нет. Приписал себе механизм, отсутствие которого сам же и признал.
Таблицу переписал: теперь по заметности BFF проигрывает. Он выигрывает четыре строки из пяти, а не пять из пяти, и так гораздо ближе к правде, хотя в реале всёж BFF как не крути лучше.
Про CSRF согласен, в статье он мелькал в скобках, хотя заслуживает отдельного места. Смысл ровно ваш: переход на куки не убирает риск, а меняет его форму. У нас стоят обе линии,
SameSite=LaxплюсSecureиHttpOnlyна куках, и поверхapp.UseAntiforgery()с токеном в каждой изменяющей форме. Именно вместе, потому чтоSameSiteне спасает от атаки с собственного поддомена и отваливается, если какому-то потоку понадобилсяSameSite=None. Вынес в отдельный подраздел.Про первую фразу принято, слово убрал из текста.
Нет конечно, это будет по типу оверинж: в статье этого не было, а надо было. BFF это браузерный паттерн, натив в него не укладывается, и встроенный веб-вью ради него был бы прямым нарушением RFC 8252, который требует системный браузер.
Для натива работает другая связка: системный браузер плюс PKCE для авторизации, хранилище ключей ОС (Keychain, Keystore) для токенов, и DPoP как основная защита. У DPoP приватный ключ генерируется в защищённом хранилище устройства и оттуда не извлекается, поэтому украденный из приложения токен без него бесполезен. Это второй слой из статьи, и для мобильных он несёт основную нагрузку, а не BFF.
Если формулировать одной фразой: BFF решает задачу для браузера, DPoP для всего остального. У браузера есть куда спрятать токен на сервере, у мобильного приложения нет, поэтому там защищают не хранение, а применение. Добавил в статью отдельный подраздел.
Вы правы, и попали ровно в место, где это так. В Tsak троттл API-ключей берёт
parts[^1]из XFF без списка доверенных прокси, модель однохоповая. В changelog 3.7.0 это допущение записано словами «assumes exactly one trusted proxy», а в статью оговорка не доехала. При цепочке Anti-DDoS → nginx правый хоп это адрес шлюза, и все за ним делят одну корзину. Причём это хуже, чем блокировка всех: правило «успешный вход обнуляет счётчик» в общей корзине сбрасывает счётчик и атакующему.Ваш рецепт правильный, и он у нас уже есть, только в соседнем продукте:
TrustedProxyResolverProcessorв redb.Identity делаетKnownProxies/KnownNetworks, проверяет сокетный пир и идёт справа налево до первого недоверенного адреса. Tsak на эту модель переведём, единственная поправка к рецепту: нераспознаваемый хоп должен обрывать обход, а не пропускаться, иначе обход уедет в клиентскую часть заголовка. Статью поправлю, чтобы правый хоп не звучал как безусловное свойство. Спасибо, замечание нашло расхождение между двумя реализациями, а не опечатку.Согласен, мне надо конечно внимательней надо быть.
Справедливо для гринфилда без ограничений. Но в банках речь не о выборе SOAP заново для нового сервиса вся парадигма вокруг уже построена: существующие потребители, ESB, регламенты аудита безопасности, мониторинг всё это годами живёт на SOAP/WS-*. Новый сервис внутри такой среды говорит на том же протоколе не потому что кто-то ностальгирует, а потому что сменить саму парадигму решение уровня всей организации, а не отдельной команды. Это больше похоже на "огромный багаж, на который оглядываешься", чем на архитектурный выбор здесь и сейчас.
тут как бы не попрёш против того что прописано и руководство просто не даст тебе внедрить новые протоколы верхнего уровня, Написано так и живём.
🤷♂️
Понимаю боль, RethinkDB был крутой техникой без бизнес-модели, обидная история. У меня хотя бы буква "base" сзади, а не "think" 😄
но ситуация другая: RethinkDB была самой базой - умерла инфраструктура. У меня данные в обычных таблицах Postgres/MSSQL/SQLite, с честными FK, если redb завтра исчезнет, ваши данные никуда не денутся, их и руками через SQL прочитать можно. Не увозим данные с собой, если что. Исходники тоже на месте.
Отличная подборка, спасибо! Заметил, что все десять концепций про организационную сторону (кто решает, когда стартовать/останавливать, как оценивать). А есть, по-моему, не менее фундаментальный пробел с инженерной стороны, который редко формулируют явно:
У системы почти всегда есть несколько валидных точек старта, и то, с какой начать, определяет фундамент, а не просто стартовую скорость. Можно начать с модели данных получится data-centric система. Можно с интеграционных контрактов message-centric. Можно с периметра безопасности более жёсткая и осторожная с рождения. Это не вопрос "стартовать раньше/позже" (как в вашем Stage Zero), а вопрос "с чего именно стартовать", когда решение строить уже принято.
И рядом с этим - архитектура, понятная разработчикам, а не просто работающая. Ни governance, ни NoEstimates, ни антихрупкость ничего не говорят о том, поймёт ли человек, пришедший через полгода, что вообще происходит в системе а это, кажется, минимум такая же по весу переменная, как всё перечисленное.
Справедливое замечание, и вы правы — Amadeus Ticket Changer действительно давно и хорошо автоматизирует пересчёт тарифа при voluntary/involuntary reissue (Category 31/33 ATPCO), это решённая задача, когда весь билет виден одному GDS. Не спорю с этим.
На практике мы так и делали: сначала смотрели, что предлагает каждый GDS сам по себе — это уже оптимальные, провалидированные через-тарифом связки, и в первую очередь оценивали именно их. А варианты из разных источников (self-connect) собирали и сравнивали уже отдельно, вторым шагом, как альтернативу — иногда через-тариф от одного GDS оказывается выгоднее, иногда комбинация из разных источников дешевле, и дальше вопрос уже в том, что важнее заказчику: гарантированная стыковка одним источником или экономия ценой риска и неудобства на пересадке.
Проблема, которую я описываю, начинается именно на этом втором шаге — там, где ATC сам предупреждает о своей границе: "tickets issued through other GDSs... are not guaranteed" Amadeus Fare Guarantee. Речь не о смене маршрута внутри одного билета, а о ситуации, когда решили, что self-connect выгоднее, и маршрут собран из трёх разных источников — три независимых билета, ни один GDS не видит два других. Замена одного плеча в такой конструкции — это не reissue внутри PNR, а согласование между источниками, которые друг о друге не знают. Ни один из GDS эту часть не решает и не может — у них просто нет данных о существовании билетов из соседних систем.
Спасибо за наводку — стоит явно назвать ATC и очертить эту границу в тексте, чтобы не создавалось впечатление, что я не в курсе существующих инструментов.
вообще интересная тема и решил покопаться, в помощь взял нейроку, и вот что вышло
____
Копнул — статья смешивает подтверждённые факты с довольно шаткой причинно-следственной теорией, и есть конкретная нестыковка по датам, которая рушит центральный тезис автора.
Что подтверждается независимо:
Водяной знак — реальный, задокументирован Fortune, TechTimes, Reuters-уровня источниками: с 2 августа 2026, статистическая метка на уровне модели (не невидимые символы), под требования Article 50 EU AI Act, применяется глобально, не только в ЕС. Это не выдумка блогера.
Opus 5 — реальная модель, вышла 24 июля 2026 (это позже, кстати, чем модели из моего собственного системного промпта — то есть для меня это тоже новость постфактум).
Жалобы на многословность и потерю смысла в Opus 5 — тоже реальные, задокументированы независимо (разбор MindStudio, тред на Hacker News, официальный GitHub issue в репозитории claude-code с конкретными измерениями).
А вот тут центральная теория автора (водяной знак → деградация Opus 5) рушится по датам. Жалобы на многословность Opus 5 фиксировались до 2 августа — материал MindStudio датирован примерно 1 августа, тред на HN старше двух недель на момент этой статьи. То есть модель уже жаловались как на "многословную и запутанную" раньше, чем вообще включили водяной знак — значит знак физически не может быть причиной того, что уже существовало до него. При этом в самом GitHub issue есть официальный анонс постмортема Anthropic с конкретными, раскрытыми причинами прошлых просадок качества (баг с уровнем effort, баг с историей размышлений, неудачное системное изменение под многословность) — то есть паттерн "нашли баг → объяснили → откатили" у них уже был, не "молчат и скрывают".
Про "уже вводили в заблуждение насчёт военного использования" — это не бьётся с тем, что реально задокументировано. По многочисленным источникам (CNN, Reuters, Al Jazeera) картина обратная: Anthropic публично и настойчиво отказывалась от неограниченного военного использования (автономное целеуказание, слежка за гражданами США), из-за чего Пентагон демонстративно понизил их статус, а компания в ответ подала в суд на правительство. Это не "скрывали военное использование", а ровно наоборот — публичный, судебный конфликт из-за того, что они слишком жёстко ограничивают именно такое использование. Автор этот пассаж явно не проверял.
Сама статья честно помечена автором как "Мнение" и "моя версия... возможно лишь частично верна" — то есть жанр разрешает спекуляцию. Но конкретно эти два места (причинность с водяным знаком и намёк на скрытое военное применение) не выдерживают проверки по датам и источникам, а не просто "спорное мнение".
а можно пример текста с меткой и пояснением?
Оба выловили не тестами, а на живом приложении: строили на этом же стеке своё — телеграм-бот через
redb.Route.Telegramкак фронт, а за ним LLM-часть, работающая с оперативными данными. Там и вылезло.Тесты были — и в этом самое интересное. Они не покрыли эти кейсы, потому что писал их я же и ровно под тот способ использования, который держал в голове. У API несколько равноправных путей, а покрыт оказался мой.
Пример прямо из этого релиза: URI эндпоинтов я всегда писал строкой, а не fluent-строителем. Поэтому расхождение кодека строителя с парсером — значения с пробелами не переживали круговой обход — у меня физически не могло воспроизвестись: этой ветки в моём коде не было. Тест «маршрут работает» проходил, потому что проверял мой путь.
С деревьями последствия серьёзнее.
WhereLeaves()замещал корневой CTE вместо того, чтобы быть предикатом поверх него, то есть запрос молча означал «свежайший лист схемы во всей базе». Ошибки нет, ответ правдоподобный — просто не про того. На одном собеседнике это невидимо в принципе; в боте со вторым пользователем видно сразу — человеку приезжает чужая история.Сейчас оба пути закрыты тестами, фикс дерева ушёл во все шесть провайдерных комбинаций и в нативное расширение SQLite.
Могу тока добавить, что рассчитать стоимость по тарифной сетке, публичные и внутренние цены, плюс система скидок, тоже не простая задача, и связать всё это с 1С.
Понял, спасибо за ссылку — интересный подход с CRDT, особенно семантическая гранулярность вместо посимвольной. Хотя тут немного другая задача: redb.SQLite — это типизированное хранилище с SQL запросами и схемой, а outbox в статье — сознательно простой конфликт-хендлинг под контролем приложения. CRDT-синк — это скорее слой ниже/сбоку, не альтернатива типизированному стору. Возьму на заметку, спасибо.
Спасибо! А что вы имели в виду под "гипер базой" — можете уточнить? Тут в статье клиентское хранилище (SQLite прямо в приложении/браузере, без сервера), не совсем понимаю, в какой момент она бы пригодилась.
статья про клиентское хранилище: SQLite встроен прямо в приложение (на телефоне) или в браузер, без сервера вообще. HyperBase — это managed-хостинг для серверного Postgres, он для другого сценария (там, где redb.Postgres/redb.MSSql). Если интересно — у меня есть статьи и про серверную часть, там как раз к месту.
Да, действительно верно.
спасибо за уточнение — DETACH PARTITION перед DROP корректнее на нагруженных таблицах. Основная тема статьи — планировщик, пример очистки был иллюстративным.
@lazarus_net
гоняю тесты с нейронкой, и я забыл вогнать поля, да и не было нужды в них, но тест дал варнинг, нейронка увидела и добавили и вот что пишет сама
тесты от
____
oidcc-basic-certification-test-plan
redb.Identity Basic OP (manual)
Variant:
server_metadata=discovery, client_registration=static_client
Alias:
redb-final-0043
Plan ID:
hdV2kmVNvRuK1
Plan Version:
5.2.0
Started:
14.07.2026, 00:43:15
Test Owner:
developer
Certification profile:
Basic OP
я не поленился и...
Вот выжимка от нейронки:
redb.Route — Apache Camel для .NET. Суть за 1 минуту.
Любая интеграция = три строки:
csharp
Что внутри:
22 транспорта — Kafka, RabbitMQ, IBM MQ, AMQP, MQTT, HTTP, gRPC, SignalR, SFTP, S3, SQS, Telegram, LDAP и ещё
30+ EIP паттернов — Choice, Splitter, Aggregator, WireTap, Saga, Circuit Breaker, Idempotent Consumer
Compiled expression engine —
${header.x++}, JSONPath, XPath →Func<IExchange, T>без интерпретатораOpenTelemetry из коробки — трейсы и метрики на каждом шаге
Транзакции через
.Transacted()— Kafka EOS, RabbitMQ confirms, IBM MQVs конкуренты:
MassTransit — 5 транспортов, нет EIP, message bus (не ESB)
NServiceBus — коммерческий после 2 эндпоинтов
Apache Camel — то же самое но на JVM
Production runtime: redb.Tsak — hot-reload, кластер, Blazor dashboard, REST API
Apache 2.0. Без per-endpoint лицензий.