Получается эдакая драка замучанных крестьян по колено в грязи на разъезжающихся ногах.
Сгенерил анимацию у себя в голове по этому промпту смеялся секунд 20, спасибо вам хотя бы только за это.
Честно скажу, я лет десять или больше не особо пользовался сайтами, почему-то считал их заранее мусором. Ну и фильмы, сериалы, книги тоже не смотрю, возможно что я в целом странный.
Подождите, а зачем вы вообще им пользуетесь, ну раньше то хоть чтобы поспорить, а теперь?
Нету. Я вам больше скажу entry под капотом все равно делает 2ой лукап в случае инсерта так что 2ой лукап не обойти никак поэтому лучше тот вариант который здесь рекомендуется т.к. хотя бы клона не будет в случае когда ключ уже есть.
В расте есть идиамотический new type для таких задач и он не одновариантный энум, а одноместный тупл. Я зашёл посмотреть почему именно одноваритный энум т.к. у меня была претензия к такому подходу в расте и вижу что в ф шарпе это имеет прекрасное объяснение, а в расте все совсем не так приятно и удобно. + тот случай для чего у нас он используется совсем иной - версионирование на очень светлое будущее.
Я лично про токио постгрес не знаю ничего, я ж вроде обьяснил кажется - команда выбрала sqlx, это было еще до того как я пришел в компанию, кстати автомодель не моя, я главный заказчик фич реализовывал ее в основном аи под присмотром нашего архитектора - т.е. это буквально вайбкодинг.
Вас устроит писать select (tracks.*)::tracks from tracks вместо select * from tracks чтобы получать переиспользуемый тип в результате запроса?
Меня лично устроит, но команду врядли.
Переименование композитов можно реализовать в конфиге генератора
Это не так просто, не все таблицы у нас заканчиваются на s потому что без с иногда лучше, не все таблицы названы в базе удачно поэтому в коде нпзвваются по другому. Не всем заходит автоматически придуманное имя структуры результата запроса. Поэтому простой конфиг для генератора не прокатит, нужны метаданные на уровне сигнатур. Вот товарищ вверху давал вам ссылку на свой модел фест подход, я пошел посмотреть, но там еще более оторванней от реальности (по сути он предлагает выкинуть N лет наработок написать модель с ноля и уже с нее генерить и базу и кверики и миграции и код; ну удачи ему в построении замков из слоновьей кости - это так никогда не работало), хотя аналог сигнатур (эксэмл схема) у него богаче и как раз позволяет эти самые мапы переименований задавать.
Скул сам по себе не позволяет дать имя эд-хок агрегату результат кверика. Если в скуле еще как то можно без этого прожить (это по сути тупл с именованными полями) то в других языках это нужно. Значит надо предоставить способ это сделать - задавать имя структуры результата. Раст не умеет в именованные туплы, по моему только сишарп на такое способен. Но туплы концептуально подошли бы так как они дак тайпятся друг на друга если совпадают по полям, тогда бы этой проблемы не стояло.
Что я хочу сказать - надо решить проблему как смапать тупл с именованными полями на структуру. Как минимум девелопер должен иметь способ задать имя этой структуры (фиг с ним что она будет сгенерированная) + указать набор трэйтов для дерайва, как максимум эта структура уже существует милион лет до начало использования генератора и надо просто смапать на нее. Вот такая задачка. Вы же генератор делаете с прицелом на разные языки, подумайте на счет возвращать туплы вместо структур возможно так будет проще, да и сам скул используют туплы.
Насколько я понимаю, если расширить pgn режимом работы с живой БД напрямую (без докера), то и вопросы к способу выведения схемы отпадут. Верно?
Верно. Только для меня слово расширить звучит странно. Генератору кроме коннекции к базе и папке с квериками вообще ничего из внешнего мира не нужно, а тут у вас терминология с ног на голову поставлена - базовая реализация это система миграций + коннекция, а расширением вы почему то называете редукцию до просто конекции.
Врядли мы будем использовать ваш генератор он для прода не готов, sqlx не подвезли и раст не в приоритете, наш прибит гвоздями к sqlx и использует не чистый скул (это самая сильная притензия) но нам ничего другого кроме sqlx и не надо, тюнится намного проще и фич имеет больше чем ваш. Зачем нам менять шило на мыло?
Пример с композитом близок, но не полностью. Представьте есть select * from tracks; и есть with... select (*)::tracks as row, 0 as result_code; Дальше по правилам именований на расте струтура для строки трэка должна быть Track без s на конце + второй кверик должен вернуть что нибудь типа struct ComplexSelectItem { row: Track, result_code: i32} Обратите внимание что я могу задать имя как всему компощиту так и сам генератор должен понять что для row ему не надо генерировать новый тип Tracks а надо использовать имя которое я задал для результата у первом обычном селекте.
Чтобы тут нормальное решение задизайнить надо проблему глубоко проработать, а дальше реализовывать это потребует изменений в логике, контракте кодогенератора, и изменения кодогенератора.
Это не сложно сделать. Я же не зря упомянул обычные языки с их импортами/экспортами - проблема решенная, решение простое, ничего изобретать и усложнять не надо.
Да, в моменте два запроса могут возвращать одинаковый набор колонок.
Большинство реальных запросов очень простые и возвращают строки целиком, такими и останутся на всегда, мне не нужно чтобы результат каждого запроса с тем же самым результатом генерировал уникальные не взаимозаменямые структуры, мне нужно роано наоборот.
Придётся менять код запросов, которые к этому изменению никакого отношения не имеют, увеличивая размер задачи.
Вот когда один из запросов поменяется и получит уникальный набор колонок в результате, вот тогда пусть генератор и сделает уникальную структуру, но не раньше, а все другие запросы что раньше шарили с этим результат продолжат его шарить, но уже без этого кверика - для них ничего не поламается. При добавлении колонки в результат ВСЕ колл сайты такого кверика надо будет руками потрогать, это вам раст, а не абы че, вы не сможете втихую проигнорировать новое поле в структуре. Зависимый от этого кверика код гарантировано поломается - так и должно быть поэтому никакого увеличения задачи нет от слова совсем.
вы за удобство расплачиваетесь воспроизводимостью сборки.
Вы эту проблему придумали или реально наблюдали в живой природе? 5 лет(но старой закрытой версией генератора) так делаем ни разу еще 2 разных артифакта не генерировалось. Смотрите база лежит в контейнере и резетится в первоначальное состояние при каждой сборке простым сбросом контейнера - откуда у вас проблемы не воспроизводимых сборок? Сами данные на типы никак не влияют, в лучшем случае можно надеятся на более качественный анализ по индексам, но это и так опциональная фича что у вас что у нас. Короче проблемы просто не существует.
Смотрите вы сюда пришли за фитбэком, а теперь мягко уклоняетесь от него. Так вот мой фидбэк такой - сигнатуры и сверху отдельные генераторы - отличная идея. Миграции которые ходят строем и кидают зигу при виде фюрера - оч плохая идея. Переписывать генератор с ноля при необходимости мальешей кастомизации - просто плохая идея.
Гегерация разных типов в расте для 100% одинаковых в ПГ вообще за гранью добра и зла только из за этого никто кроме вас этим пользоваться не будет.
Если не знаете куда двигать проект простой совет - интеграция в сложные реальные кодобазы должна быть максимально простая поэтому никаких предположений о том как правильно - как есть так и правильно, а философию оставьте себе. Генератор должен упрощать жизнь, а не усложнять.
Это уж очень тонкая настройка пошла. Так ли она важна практически?
Это очень важное практическое свойство. Там выше вы писали что каждый кверик генерирует свой набор типов в расте - это ошибка проектирования. Все кверики врзвращаюшие одинаковые данные должны использовать одинаковые типы иначе как всем этим пользоваться? Писать руками from для каждого кверика в доменный тип? А зачем тогда вообще использовать ваш генератор?
Поймите ценность гегератора не в том что бы с ноля начинать писать проект по феншую (как автор генератора считает правильным) а в том чтобы он облегчал практические задачи (особенно бойлерплэйт) вокруг уже существующего кода. Доменные типы уже есть, никто не хочет тратить время на написание в ручную и поддержку преобразований в/из типов базы. Это кстати ответ почему sqlx он позволяет смапать доменный тип на тип базы и проверить тоже в компил тайме только дороже по времени компиляции чем наш генератор. Еще sqlx умееет в динамические кверики, ну и самый главный критерий - так решила команда.
Реализовывать дорого как в плане дизайна, так и усложнения системы
Неа, это как раз не оч сложно, но вероятно не так хорошо дружит с вашей идеей раздельной компиляции, но все нормальные языки умеют в модули импорт/экспорт - это решение для этой задачи если прям оч хочется раздельной компиляции, но работа с пг / составление сигнатур это большая часть времени, код ген намного быстрее так что имхо это та самая оптимизация которая все только усложняет.
Сейчас правило простое: у каждого запроса свои типы. Чего предлагаемое усложнение нам даст с практической точки зрения?
Ну надеюсь из вышесказанного понятно зачем это надо. У нас много таких квериков уже и это очень важно чтобы интеграция с существующим кодом была максимально проста. Ваше боязнь скрытых зависимостей необоснована, во первых они не скрытые, а задаются самими типами из базы - ну какой смысл генерировать 100500 обсалютно одинаковых (по полям) но совершенно ге вщаимозаменяемых структур? Если один кверик читающий строку целиком поломался то очевидно все остальные которые выдают точно такую же строку обязаны поломаться, а при ваших 100500 разных типов я буду должен руками фиксить это не один раз а 100500.
Я понял у нас с вами несовместимость по философии - вам важно шашечки / как "правильно", а нам важно ехать. На практике это значит, что генератор не имеет право ничего навязывать/требовать изменить в проекте, мне не надо тратить время писать какие то скрипты, что бы после миграций еще и сдампить схему чтобы потом ее импортнуть во временную базу ровно для того что уже и так доступно без всех этих телодвижений. Юникс философия, утилита должна заниматься своим делом и не лезть со своими советами/требованиями как жить всем остальным. Никто не будет танцевать вокруг того, что там вы как автор генератора считаете правильным. Если ваш генератор больно подружить с тем что есть, ну значит не судьба. А ваш генератор больно подружить. Простые/маленькие кастомизации должны требовать простых/маленьких усилий. Поменять драйвер на sqlx это большая кастомизация - писать новый генератор адекватная затрата. Смапать тип из базы на доменный это маленькая задача - писать для этого новый генератор не адекватное усилие. Подключить генератор к существующей базе должно быть оч просто, а не напиши скрипт который сдампит базу. В общем с такой философией нам не попути.
А можно ли подружить ваш пигини с sqlx? Я уже понял что придется писать свой генератор, вопрос на сколько это сложно?
Допустим у меня один сэлект возвращает всю строку целиком. По моим конвенциям названия таблиц множественное число, а в расте я хочу что бы названия типов были единственного числа, значит мне нужно переименовывать пгшные типы по правилам в общем случае и я бы хотел вручную задать имя типа в расте не по правилам когда надо. Генератор такое умеет? Думаю правило не сложно сделать в самом генераторе, а вот как передать метаинформацию в гегератор чтобы смапать пгшный тип на произвольный растовский тип? По идее это мапа должна быть в ваших файлах сигнатур, но я не заметил по списку того что там может быть возможность задать мапу. Либо сигнатуры должны описывать генератор специфичные секции либо это должен быть еще один слой поверх сигнатур. Короче не похоже что без больших изменений это возможно - а надо.
Дальше вопрос по композитам, продолжение вопроса переименований, но в общем виде. Допустим мой кверик возвращает строку целиком + еще один скалярный флаг/енум. У меня есть такие кверики и я бы хотел что бы часть результирующего композита, которая строка, получила тип в расте тот же что я задал для обычного селекта * для этой таблицы. Короче мне надо не просто задавать производьные имена типам в расте, но и еще чтобы генератор понимал, что он должен использовать эти имена консистентно и в композитах тоже, что бы раст обьекты совпадали.
Миграции - у нас сложные миграции не чистый скул, скул + код. Есть миграции на тайпскрипте и недавно начали писать на расте. Как подружить ваш пигини с такими миграциями? Думаю никак, тут у вас ошибка проектирования генератор не должен требовать каких либо миграций вообще. Это не его дело, ему нужна тупо конекция к аптудэйт базе, а как она мигрируется это не его забота. Малотого анализ работает не совсем одинаково на пустой и не пустой базе, но это слабый аргумент т.к. к прод базе конечно никто ради анализа не полезет, но все равно очень удобно иметь не пустую базу (у нас даунсайз прода в отдельном контейнере и мигрируется также как и прод) и дебажить кверики на ней. Да и генерация быстрее не надо мигрировать каждый раз чтобы сигнатуры посчитать.
Я это все спрашиваю не просто так, у нас есть похожий генератор, только проще. Ограничен пг -> раст. Мы используем sqlx, тоже есть много чего, анализ индексов телеметрия (у вас кстати нет), композиты, нулаблы, форс нот нулл в результатах, компайл тайм генерация. Короче разница с вашим проектом в простоте https://github.com/thepartly/automodel
Ваш пигини конечно более правильный архитектурно (за исключением миграций), но нам ехать, а не шашечки.
Убирать нулл как элемент типа - вы статью то про ошибку на миллиард почитайте. Суть ошибки в том что нулл должен быть НЕ частью домена типа, а отдельным типом, что бы в принципе без присяданий нельзя было работать с нуллтипами, которые в свою очередь сума нул типа и доменного типа. Вот и всё.
Т.е. достаточно поменять экономическую логику (привет АНБ) что бы совместимость с существующим с++ кодом перестала быть самой важной и вся ваша логика рушится следом.
Также я не оч представляю вас топящим за использование раста в гипотетический ситуации что кто-то выкатит транспайлер из раста в плюсы. Раст вам просто не нравится и ничего в мире это не поменяет.
Я думаю по той же причине почему формальная система не может быть одновременно полной и не противоречивой. И то и се открывает путь к двойным стандартам, но лично мне больше импонирует неполнота чем противоречия - есть хотя бы какой островок без костылей, но даже (неполную и) непротиворечивую модель никто пока так и не родил, как впрочем и полную.
Мне кажется у вас есть какие то обоснования этим предпочтениям.
Какой такой существует фатальный недостаток у двойных стандартов из за чего с ними следуют бороться? Существует ли, хотя бы теоретически, социум без двойных стандартов?
По-моему, двойные стандарты это следствие двух фундаментальных свойств: невозможно создать непротиворечивую социальную модель и люди существа иеерахические. Из этого следует неизбежное возникновение двойных стандартов.
Это как костыли в бизнес логике, без них невозможно обойтись, да даже както минимизировать не особо получается, но они работают.
Наблюдаемые данные они общие для всех ну хотя бы сошлись в выводах уже не плохо.
Но мне лично интересны чужие предпочтения и как люди их обосновывают. И чем необычнее предпочтения тем интереснее. Именно поэтому меня заинтересовал этот комментарий - борьба с дискриминацией детей это весьма необычное предпочтение.
Ну т.е. под ширмой борьбы с дискриминацией скрывается просто обычная борьба ценностей, моя свобода самая свободная свобода, а кто против тот враг свободы и ему никаких свобод.
Я не знаю кто такие МАРы и как они связаны с радужными.
Я так и не понял по каким критериям вы выбираете с какими дискриминациями вам жить норм, а с какими нет.
Ну и если я правильно понял, то смысл борьбы с дискриминациями ровно в одном, чтобы навязать свои ценности и заодно свой набор предпочтительных дискриминаций или в чем то другом?
Здравствуйте, стало скучно пошел специально поискать ваших свежих коментов, вот этот меня заинтересовал.
А зачем нужно бороться с этой конкретной дискриминацией? А нужно со всеми дискриминациями бороться или есть какие-то критерии? Если уж совсем уходить на метауровни дискуссии, а не является ли борьба с дискриминациями дискриминацией по отношению к дискриминаторам?
Вобщем я как обычно запутался помогите распутаться пожалуйста.
Попробуйте подключить мак к какому-то и телевизору, я наблюдал и продолжаю наблюдать эти страдания людей на каждом митинге за 10+ лет лучше точно не стало.
Фильтр один микрон это самый обычный входной фильтр в домашних фильтрах из 1/2/3 флаконов даже без осмоса. Переводя на простой русский - фильтрация как для питьевой воды. Не супер дёшево, но р не ужас как дорого.
Так обычно никто и не требует отказываться от кучи там где есть "достаточно большой обьем рамы", такие требования обычно там где этой самой рамы недостаточно, что бы работать через кучу, но достаточно если работать напрямую.
Нет. Куча не обязана вам вернуть обьект, а при достаточно большом массиве такой ситуации быть не может. Именно это и есть ключевая причина почему запрещают кучу - малок имеет право вернуть нулл. Вторая причина это время жизни обьекта, но пул тут не спасение конечно. Спасением будет один объект один адрес, но тогда размер массива совсем неприличный будет для чего либо полезного. В такой модели утечек не бывает, точнее каждый обьект это по сути утечка и поэтому нет никакой разницы что она есть что ее нет.
Неиспользование кучи != запрет на переисеользование памяти под разные обьекты при условии соблюдения времен жизни.
Сгенерил анимацию у себя в голове по этому промпту смеялся секунд 20, спасибо вам хотя бы только за это.
Подождите, а зачем вы вообще им пользуетесь, ну раньше то хоть чтобы поспорить, а теперь?
Нету. Я вам больше скажу entry под капотом все равно делает 2ой лукап в случае инсерта так что 2ой лукап не обойти никак поэтому лучше тот вариант который здесь рекомендуется т.к. хотя бы клона не будет в случае когда ключ уже есть.
В расте есть идиамотический new type для таких задач и он не одновариантный энум, а одноместный тупл. Я зашёл посмотреть почему именно одноваритный энум т.к. у меня была претензия к такому подходу в расте и вижу что в ф шарпе это имеет прекрасное объяснение, а в расте все совсем не так приятно и удобно. + тот случай для чего у нас он используется совсем иной - версионирование на очень светлое будущее.
Я лично про токио постгрес не знаю ничего, я ж вроде обьяснил кажется - команда выбрала sqlx, это было еще до того как я пришел в компанию, кстати автомодель не моя, я главный заказчик фич реализовывал ее в основном аи под присмотром нашего архитектора - т.е. это буквально вайбкодинг.
Меня лично устроит, но команду врядли.
Это не так просто, не все таблицы у нас заканчиваются на s потому что без с иногда лучше, не все таблицы названы в базе удачно поэтому в коде нпзвваются по другому. Не всем заходит автоматически придуманное имя структуры результата запроса. Поэтому простой конфиг для генератора не прокатит, нужны метаданные на уровне сигнатур. Вот товарищ вверху давал вам ссылку на свой модел фест подход, я пошел посмотреть, но там еще более оторванней от реальности (по сути он предлагает выкинуть N лет наработок написать модель с ноля и уже с нее генерить и базу и кверики и миграции и код; ну удачи ему в построении замков из слоновьей кости - это так никогда не работало), хотя аналог сигнатур (эксэмл схема) у него богаче и как раз позволяет эти самые мапы переименований задавать.
Скул сам по себе не позволяет дать имя эд-хок агрегату результат кверика. Если в скуле еще как то можно без этого прожить (это по сути тупл с именованными полями) то в других языках это нужно. Значит надо предоставить способ это сделать - задавать имя структуры результата. Раст не умеет в именованные туплы, по моему только сишарп на такое способен. Но туплы концептуально подошли бы так как они дак тайпятся друг на друга если совпадают по полям, тогда бы этой проблемы не стояло.
Что я хочу сказать - надо решить проблему как смапать тупл с именованными полями на структуру. Как минимум девелопер должен иметь способ задать имя этой структуры (фиг с ним что она будет сгенерированная) + указать набор трэйтов для дерайва, как максимум эта структура уже существует милион лет до начало использования генератора и надо просто смапать на нее. Вот такая задачка. Вы же генератор делаете с прицелом на разные языки, подумайте на счет возвращать туплы вместо структур возможно так будет проще, да и сам скул используют туплы.
Верно. Только для меня слово расширить звучит странно. Генератору кроме коннекции к базе и папке с квериками вообще ничего из внешнего мира не нужно, а тут у вас терминология с ног на голову поставлена - базовая реализация это система миграций + коннекция, а расширением вы почему то называете редукцию до просто конекции.
Врядли мы будем использовать ваш генератор он для прода не готов, sqlx не подвезли и раст не в приоритете, наш прибит гвоздями к sqlx и использует не чистый скул (это самая сильная притензия) но нам ничего другого кроме sqlx и не надо, тюнится намного проще и фич имеет больше чем ваш. Зачем нам менять шило на мыло?
Пример с композитом близок, но не полностью. Представьте есть select * from tracks; и есть with... select (*)::tracks as row, 0 as result_code; Дальше по правилам именований на расте струтура для строки трэка должна быть Track без s на конце + второй кверик должен вернуть что нибудь типа struct ComplexSelectItem { row: Track, result_code: i32} Обратите внимание что я могу задать имя как всему компощиту так и сам генератор должен понять что для row ему не надо генерировать новый тип Tracks а надо использовать имя которое я задал для результата у первом обычном селекте.
Это не сложно сделать. Я же не зря упомянул обычные языки с их импортами/экспортами - проблема решенная, решение простое, ничего изобретать и усложнять не надо.
Большинство реальных запросов очень простые и возвращают строки целиком, такими и останутся на всегда, мне не нужно чтобы результат каждого запроса с тем же самым результатом генерировал уникальные не взаимозаменямые структуры, мне нужно роано наоборот.
Вот когда один из запросов поменяется и получит уникальный набор колонок в результате, вот тогда пусть генератор и сделает уникальную структуру, но не раньше, а все другие запросы что раньше шарили с этим результат продолжат его шарить, но уже без этого кверика - для них ничего не поламается. При добавлении колонки в результат ВСЕ колл сайты такого кверика надо будет руками потрогать, это вам раст, а не абы че, вы не сможете втихую проигнорировать новое поле в структуре. Зависимый от этого кверика код гарантировано поломается - так и должно быть поэтому никакого увеличения задачи нет от слова совсем.
Вы эту проблему придумали или реально наблюдали в живой природе? 5 лет(но старой закрытой версией генератора) так делаем ни разу еще 2 разных артифакта не генерировалось. Смотрите база лежит в контейнере и резетится в первоначальное состояние при каждой сборке простым сбросом контейнера - откуда у вас проблемы не воспроизводимых сборок? Сами данные на типы никак не влияют, в лучшем случае можно надеятся на более качественный анализ по индексам, но это и так опциональная фича что у вас что у нас. Короче проблемы просто не существует.
Смотрите вы сюда пришли за фитбэком, а теперь мягко уклоняетесь от него. Так вот мой фидбэк такой - сигнатуры и сверху отдельные генераторы - отличная идея. Миграции которые ходят строем и кидают зигу при виде фюрера - оч плохая идея. Переписывать генератор с ноля при необходимости мальешей кастомизации - просто плохая идея.
Гегерация разных типов в расте для 100% одинаковых в ПГ вообще за гранью добра и зла только из за этого никто кроме вас этим пользоваться не будет.
Если не знаете куда двигать проект простой совет - интеграция в сложные реальные кодобазы должна быть максимально простая поэтому никаких предположений о том как правильно - как есть так и правильно, а философию оставьте себе. Генератор должен упрощать жизнь, а не усложнять.
Это очень важное практическое свойство. Там выше вы писали что каждый кверик генерирует свой набор типов в расте - это ошибка проектирования. Все кверики врзвращаюшие одинаковые данные должны использовать одинаковые типы иначе как всем этим пользоваться? Писать руками from для каждого кверика в доменный тип? А зачем тогда вообще использовать ваш генератор?
Поймите ценность гегератора не в том что бы с ноля начинать писать проект по феншую (как автор генератора считает правильным) а в том чтобы он облегчал практические задачи (особенно бойлерплэйт) вокруг уже существующего кода. Доменные типы уже есть, никто не хочет тратить время на написание в ручную и поддержку преобразований в/из типов базы. Это кстати ответ почему sqlx он позволяет смапать доменный тип на тип базы и проверить тоже в компил тайме только дороже по времени компиляции чем наш генератор. Еще sqlx умееет в динамические кверики, ну и самый главный критерий - так решила команда.
Неа, это как раз не оч сложно, но вероятно не так хорошо дружит с вашей идеей раздельной компиляции, но все нормальные языки умеют в модули импорт/экспорт - это решение для этой задачи если прям оч хочется раздельной компиляции, но работа с пг / составление сигнатур это большая часть времени, код ген намного быстрее так что имхо это та самая оптимизация которая все только усложняет.
Ну надеюсь из вышесказанного понятно зачем это надо. У нас много таких квериков уже и это очень важно чтобы интеграция с существующим кодом была максимально проста. Ваше боязнь скрытых зависимостей необоснована, во первых они не скрытые, а задаются самими типами из базы - ну какой смысл генерировать 100500 обсалютно одинаковых (по полям) но совершенно ге вщаимозаменяемых структур? Если один кверик читающий строку целиком поломался то очевидно все остальные которые выдают точно такую же строку обязаны поломаться, а при ваших 100500 разных типов я буду должен руками фиксить это не один раз а 100500.
Я понял у нас с вами несовместимость по философии - вам важно шашечки / как "правильно", а нам важно ехать. На практике это значит, что генератор не имеет право ничего навязывать/требовать изменить в проекте, мне не надо тратить время писать какие то скрипты, что бы после миграций еще и сдампить схему чтобы потом ее импортнуть во временную базу ровно для того что уже и так доступно без всех этих телодвижений. Юникс философия, утилита должна заниматься своим делом и не лезть со своими советами/требованиями как жить всем остальным. Никто не будет танцевать вокруг того, что там вы как автор генератора считаете правильным. Если ваш генератор больно подружить с тем что есть, ну значит не судьба. А ваш генератор больно подружить. Простые/маленькие кастомизации должны требовать простых/маленьких усилий. Поменять драйвер на sqlx это большая кастомизация - писать новый генератор адекватная затрата. Смапать тип из базы на доменный это маленькая задача - писать для этого новый генератор не адекватное усилие. Подключить генератор к существующей базе должно быть оч просто, а не напиши скрипт который сдампит базу. В общем с такой философией нам не попути.
А можно ли подружить ваш пигини с sqlx? Я уже понял что придется писать свой генератор, вопрос на сколько это сложно?
Допустим у меня один сэлект возвращает всю строку целиком. По моим конвенциям названия таблиц множественное число, а в расте я хочу что бы названия типов были единственного числа, значит мне нужно переименовывать пгшные типы по правилам в общем случае и я бы хотел вручную задать имя типа в расте не по правилам когда надо. Генератор такое умеет? Думаю правило не сложно сделать в самом генераторе, а вот как передать метаинформацию в гегератор чтобы смапать пгшный тип на произвольный растовский тип? По идее это мапа должна быть в ваших файлах сигнатур, но я не заметил по списку того что там может быть возможность задать мапу. Либо сигнатуры должны описывать генератор специфичные секции либо это должен быть еще один слой поверх сигнатур. Короче не похоже что без больших изменений это возможно - а надо.
Дальше вопрос по композитам, продолжение вопроса переименований, но в общем виде. Допустим мой кверик возвращает строку целиком + еще один скалярный флаг/енум. У меня есть такие кверики и я бы хотел что бы часть результирующего композита, которая строка, получила тип в расте тот же что я задал для обычного селекта * для этой таблицы. Короче мне надо не просто задавать производьные имена типам в расте, но и еще чтобы генератор понимал, что он должен использовать эти имена консистентно и в композитах тоже, что бы раст обьекты совпадали.
Миграции - у нас сложные миграции не чистый скул, скул + код. Есть миграции на тайпскрипте и недавно начали писать на расте. Как подружить ваш пигини с такими миграциями? Думаю никак, тут у вас ошибка проектирования генератор не должен требовать каких либо миграций вообще. Это не его дело, ему нужна тупо конекция к аптудэйт базе, а как она мигрируется это не его забота. Малотого анализ работает не совсем одинаково на пустой и не пустой базе, но это слабый аргумент т.к. к прод базе конечно никто ради анализа не полезет, но все равно очень удобно иметь не пустую базу (у нас даунсайз прода в отдельном контейнере и мигрируется также как и прод) и дебажить кверики на ней. Да и генерация быстрее не надо мигрировать каждый раз чтобы сигнатуры посчитать.
Я это все спрашиваю не просто так, у нас есть похожий генератор, только проще. Ограничен пг -> раст. Мы используем sqlx, тоже есть много чего, анализ индексов телеметрия (у вас кстати нет), композиты, нулаблы, форс нот нулл в результатах, компайл тайм генерация. Короче разница с вашим проектом в простоте https://github.com/thepartly/automodel
Ваш пигини конечно более правильный архитектурно (за исключением миграций), но нам ехать, а не шашечки.
Убирать нулл как элемент типа - вы статью то про ошибку на миллиард почитайте. Суть ошибки в том что нулл должен быть НЕ частью домена типа, а отдельным типом, что бы в принципе без присяданий нельзя было работать с нуллтипами, которые в свою очередь сума нул типа и доменного типа. Вот и всё.
Т.е. достаточно поменять экономическую логику (привет АНБ) что бы совместимость с существующим с++ кодом перестала быть самой важной и вся ваша логика рушится следом.
Также я не оч представляю вас топящим за использование раста в гипотетический ситуации что кто-то выкатит транспайлер из раста в плюсы. Раст вам просто не нравится и ничего в мире это не поменяет.
А я готов с оружием в руках (на сколько меня хватит) отстаивать обратную точку зрения - расправиться со всем, что неизбежно ведёт к такому результату.
Я думаю по той же причине почему формальная система не может быть одновременно полной и не противоречивой. И то и се открывает путь к двойным стандартам, но лично мне больше импонирует неполнота чем противоречия - есть хотя бы какой островок без костылей, но даже (неполную и) непротиворечивую модель никто пока так и не родил, как впрочем и полную.
Мне кажется у вас есть какие то обоснования этим предпочтениям.
Какой такой существует фатальный недостаток у двойных стандартов из за чего с ними следуют бороться? Существует ли, хотя бы теоретически, социум без двойных стандартов?
По-моему, двойные стандарты это следствие двух фундаментальных свойств: невозможно создать непротиворечивую социальную модель и люди существа иеерахические. Из этого следует неизбежное возникновение двойных стандартов.
Это как костыли в бизнес логике, без них невозможно обойтись, да даже както минимизировать не особо получается, но они работают.
Это как раз важнее чем
Наблюдаемые данные они общие для всех ну хотя бы сошлись в выводах уже не плохо.
Но мне лично интересны чужие предпочтения и как люди их обосновывают. И чем необычнее предпочтения тем интереснее. Именно поэтому меня заинтересовал этот комментарий - борьба с дискриминацией детей это весьма необычное предпочтение.
Ну т.е. под ширмой борьбы с дискриминацией скрывается просто обычная борьба ценностей, моя свобода самая свободная свобода, а кто против тот враг свободы и ему никаких свобод.
Я не знаю кто такие МАРы и как они связаны с радужными.
Я так и не понял по каким критериям вы выбираете с какими дискриминациями вам жить норм, а с какими нет.
Ну и если я правильно понял, то смысл борьбы с дискриминациями ровно в одном, чтобы навязать свои ценности и заодно свой набор предпочтительных дискриминаций или в чем то другом?
Здравствуйте, стало скучно пошел специально поискать ваших свежих коментов, вот этот меня заинтересовал.
А зачем нужно бороться с этой конкретной дискриминацией? А нужно со всеми дискриминациями бороться или есть какие-то критерии? Если уж совсем уходить на метауровни дискуссии, а не является ли борьба с дискриминациями дискриминацией по отношению к дискриминаторам?
Вобщем я как обычно запутался помогите распутаться пожалуйста.
Попробуйте подключить мак к какому-то и телевизору, я наблюдал и продолжаю наблюдать эти страдания людей на каждом митинге за 10+ лет лучше точно не стало.
Фильтр один микрон это самый обычный входной фильтр в домашних фильтрах из 1/2/3 флаконов даже без осмоса. Переводя на простой русский - фильтрация как для питьевой воды. Не супер дёшево, но р не ужас как дорого.
Так обычно никто и не требует отказываться от кучи там где есть "достаточно большой обьем рамы", такие требования обычно там где этой самой рамы недостаточно, что бы работать через кучу, но достаточно если работать напрямую.
Нет. Куча не обязана вам вернуть обьект, а при достаточно большом массиве такой ситуации быть не может. Именно это и есть ключевая причина почему запрещают кучу - малок имеет право вернуть нулл. Вторая причина это время жизни обьекта, но пул тут не спасение конечно. Спасением будет один объект один адрес, но тогда размер массива совсем неприличный будет для чего либо полезного. В такой модели утечек не бывает, точнее каждый обьект это по сути утечка и поэтому нет никакой разницы что она есть что ее нет.
Неиспользование кучи != запрет на переисеользование памяти под разные обьекты при условии соблюдения времен жизни.