А есть ли ЯП, которые умеют обходиться без системы сборки?

Итого mybatis и activerecrod приведет к тому, что будет один запрос на одну сущность. А когда будет нужно оптимизировать чтоб вытаскивать несколько связанных сущностей за раз, то появятся множество запросов с join'ами для разных комбинаций этих сущностей. SQL будет занимать места значительно больше остального кода. Не будет кеша объектов, вытащенные объекты не будут связанны друг с другом, согласование и детект изменений будет только чрез базу.

Ну у lombook, вроде, во время компиляции, но это делается средствами языка, а не системы сборки.

Логика подсказывает, что по крайней мере нужен плагин в сборщике для генерации/модификации классфайлов в момент компиляции.

Разве pip это система сборки? Я думал это штука для управления зависимостями, ну как apt/pacman/yast/etc. Не?

Логика подсказывает, что по крайней мере нужен плагин в сборщике для генерации/модификации классфайлов в момент компиляции.

https://projectlombok.org/setup/javac

Just put lombok on the classpath when compiling with any javac (version 1.6 - 1.8): javac -cp lombok.jar ....

Хз. Тут ничего такого про это нет.

Руками я и запрос к БД напишу.

Enjoy your SQL injections.

Разве pip это система сборки?

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

Я думал это штука для управления зависимостями, ну как apt/pacman/yast/etc. Не?

Так система сборки проекта и подразумевает управления зависимостями + компиляция, т.е. запуск чего-то там с ключами, если надо. Можно и из apt сделать систему сборки. Еще есть портаж, например.

ORM нужен, чтобы из бд сделать тоже самое, только в виде структур твоего любимого яп.

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

Не нужен для этого никакой ORM

Ну так-то согласен. Сейчас вот у меня стоооолько головняка из-за того, что кто-то решил, что ORM - это круто и универсально.

Есть image-based языки, в которых все исходники скармливаются через консоль. Например, SQL. Однако потом возникает желание отслеживать версии исходников, в т.ч. для разных платформ и распространять их - так возникает система сборки. Возникают библиотеки - возникает нужда и в пакетном менеджере. Т.е. существующая инфраструктура сборки объективно необходима. В оберонах иногда есть прибитые гвоздями соглашения о директориях и именах. Система сборки встроена в сам язык. Однако опять же, для всякой там кросс-компиляции всё равно нужна какая-то настройка. Кроме того, там вручную нужно выискивать и ставить библиотеки, хотя в современных технологиях для этого есть пакетные менеджеры.

Т.е. теоретически в частных случаях это возможно, но вообще говоря, это невозможно и не нужно.

Другое дело, что в мире Си это сделано через попу, как и всё в мире Си. Например, нет нормального способа отлаживать мейкфайлы и баш-скрипты. Кривые языки программирования, в которых опечатка в имени переменной или вовсе отсутствующая переменная не вызывают ошибку времени компиляции (баш и мейк оба такова). Т.е. ошибки проектирования сплошь. Далее всё это постоянно меняется и возникают новые слои протекающих абстракций, типа Cmake. Плохо документировано. Плохая диагностика. Привычка игнорировать ошибки в скриптах. Важно и то, что сборка - это процесс долгий. Именно отсюда и возникает боль. Сама по себе задача сборки, если её рассматривать как бизнес-процесс, ничего особого из себя не представляет. Не сложнее, чем собрать расходную накладную в АШАН. Только непреодолимая привычка жрать ставший уже родным кактус делает её сверхсложной.

А чё мне их бояться, если юзер всё тоже самое может и имеет право из psql сделать? Ну попортит сам себе данные, ну ССЗБ

А чё мне их бояться, если юзер всё тоже самое может и имеет право из psql сделать?

У тебя юзеры в sql имеют доступ? У нас тут что, опять утечка в криокамере?

Согласно ТЗ, имеют.

Дичь какая-то. Зачем юзерам sql? Что за юзеры такие, которые могут в sql?

Пользователи бывают разные.

Что за юзеры такие, которые могут в sql?

Аналитики, например.

Но для них же есть olap. За что вы так с ними? Просто в базе может хранится всякое типа старых записей и простая выборка может оказаться очень не простой.

За что вы так с ними?

Это не я. Просто знаю о таких компаниях.

Дичь какая-то. Зачем юзерам sql? Что за юзеры такие, которые могут в sql?

Наверное америка. У них давно прошла информатизация, бизнес аналитики разных возвратов умеют sql, для них это типа как exel для офисных работников. Вот допустим кейс, нужен полугодовой отчет, для этих целей у аналитика где-то спрятан огромный sql, его и запускают, если результаты не нравятся, его меняют, отбрасывают что не нужно, не важно и т.д. Программисты пытаются автоматизировать такие отчеты, но банально на все такие штуки не хватало времени.

Я ещё могу понять права на чтение, но зачем юзеру права на запись в БД?

1) из-под слона даже макаку можно научить в постгрес лазить

2) а сопровождать кто будет? мы? так заказчик на иглу не хочет

очевидно, чтобы менять содержимое БД

то, на которое у его аккаунта есть права, разумеется

Вот допустим кейс, нужен полугодовой отчет, для этих целей у аналитика где-то спрятан огромный sql, его и запускают, если результаты не нравятся, его меняют, отбрасывают что не нужно, не важно и т.д. Программисты пытаются автоматизировать такие отчеты, но банально на все такие штуки не хватало времени.

Но если у аналитиков хватает мозгов на sql, то может стоит им просто выделить отдельную базу?

Да и в php самый популярный orm так работает, описываешь схему на каком-то xml или yaml и он тебе генерит классы, sql файлы и прочее. Жутко неудобно, конечно, по ряду причин, но иначе совсем убого в языках без метаклассов и прочей магии.

И что должно быть в бд, чтобы имело смысл давать это изменять юзеру? Это же какой-то бред.

В питоне, например, классы можно создавать на лету одной строчкой.

In [1]: MyList = type('MyList', (list,), {'foo':1})

In [2]: MyList
Out[2]: __main__.MyList

In [3]: MyList()
Out[3]: []

In [4]: MyList().foo
Out[4]: 1

схему на каком-то xml или yaml

Трешак. На кой чёрт описывать схему в xml, если можно сразу в SQL? Если уж нужно генерять классы из какого-то описания, надо быть наркоманом, чтобы не юзать в качестве описания специально созданный для этого DDL.

допустим, на одной их прошлых работ, это было ПО для логистики и юзер там вбивал различные коэффициенты настроек маршрутов авто (расход бензина, габариты, пр., пр. - дохрена параметров), иногда даже приходилось карты вручную править, т.к. у яндекс- и прочих карт проблемы с актуальностью

да мало ли какую хрень юзеру потребуется в БД внести

Такое происходит только когда разрабы мышей не ловят.

В реальности у тебя на первой key-value таблице orm превратиться в тыкву.

4.2

https://gist.github.com/grakic/5c8c274b1a75fba2fc3b3572d7de064b

https://github.com/mvpdev/django-eav

придётся все кучу всего делать руками

не придется, по крайней мере не сложнее sql, если orm достаточно гибкая.

нагенерить говнокода из по схеме твоей субд

Нагенерить модели из схемы можно.

Думать она не умеет, но позволяет избавить от рутины.

Но если у аналитиков хватает мозгов на sql, то может стоит им просто выделить отдельную базу?

Может быть, но там было слишком много тонкостей. Представь что ты к готовой базе пишешь CRUD он покрыл 97% всех необходимых манипуляций с данными, но оставшиеся 3% это набор абсолютно разных вещей которые могут понадобится, каждый отельный кейс редок, но если такие события не различать, то можно сказать, что они возникали часто.

Вот кстати, у меня есть эмпирическое наблюдение по поводу покрытия всех возможных кейсов. В некоторых конторах есть требование по покрытию кода юнит тестами. Покрыть код на 80% не составляло труда, 90% занимало в два раза больше времени чем покрытие на 80%, а 100% это почти никогда!

Ну можно, наверное и наоборот, нагенерить их из существующей схемы. Или из UML какого-нить.

struct Obj 
{
QVector<QVariant> data;
unique_ptr<Class> class_id;
...
};

class Class
{
 public:
 QString name;
 QVector<QString> var_names;
 ...
};

плюсы тоже умеют, такие штуки больше интересны в контексте статической типизации или, хотя бы, кодогенерации, чтобы оно потом в разные IntelliSense без костылей подтягивалось - вот это вот всё

в смысле? а что вы предлагаете? вот в том описанном случае, например

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

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

Процедурные макросы в расте? См. diesel.

Да это понятно, тут больше огр.вопрос. Зачем в рабочей базе что-то давать делать, когда можно для этого сделать специальную базу и пусть там делают что хотят на здоровье.

Ты нихрена не понимаешь суть проблемы.
У тебя объект, у него куча свойств, к нему куча параметров, которые сами состоят из, собственно, параметра с кучей свойств и значением этого параметра, с свойствами, в которых есть, скажем, его дата существования. Итого 3 таблицы: объект, параметры, значения параметров для объекта. Так вот, когда ты берешь объект жадный fetch тащит за собой всё это дерьмо, причём вместе с неактуальными значениями, причём независимо от того, насколько твоя orm «гибкая». Может сделать не жадный fetch, но твоя orm будет тащить всё дерьмо, когда ты захочешь узнать параметры объекта. No way короче.

Да, по смыслу похоже на то что я хочу, в части кодогенерации. А оно может в теории, например, разобрать xml файл, на лету сделать запись в БД соответствующих таблиц и функций, а потом, на основе того же xml-ника сгенерировать процедурный макрос, и его также на лету уже подхватить через diesel?

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

Даже всякие хваленые os-independent one-click нпмы ставят себе внутри полноценный питон и при этом еще требуют попрыгать вокруг него с правильной версией визуалстудии. Если временно отбросить вопрос нахера, то спроси себя хотя бы как это все упаковать в либу, чтобы она весила менее гигабайта и не покрылась пылью в тот же день.

Может сделать не жадный fetch, но твоя orm будет тащить всё дерьмо, когда ты захочешь узнать параметры объекта.

так это единственно правильный вариант при чтении БД - вот вытащил ты строку из БД, в ней id - пользователь ушёл покурить на час, если ты сразу же вытащишь все данные по этому id, то когда юзер вернётся, они могут стать тупо неактуальными

Замечательно живётся. В модуле пишешь require на используемые модули и они при необходимости перекомпилируются. Так как система сборки изолированная (каждый модуль компилируется в отдельном окружении), то работает гораздо лучше, чем ASDF в Common Lisp.

В чем разница между использованием orm и не использованием тут? Ты можешь в рамках orm делать аналогичные запросы. Если тебе нужны конкретные свойства, указывай их.

Но вообще это фигня какая-то надуманная. Такие вещи надо хранить в каком-нить jsonfield, в которые orm, внезапно, умеют.

SQL injections происходят не от ручных запросов, а от кривого склеивания текста запроса с его аргументами.

единственно правильный вариант

Неверно. Изоляция бывает разная, как и кейсы, где она применяется. При генерации синтетики (себестоимость, налоги, расчеты-распределения по к-л базе) ты работаешь в снапшоте, чтобы конкурирующие изменения во время серии запросов тебя не трогали, а при конфликте все либо откатывалось, либо сериализовалось. А вот в уи обычно сидят в твоем рид-коммиттеде или вообще в коротких транзакциях. Нельзя взять что-то одно и на этом построить инф.систему.

Прикинь ты считал прибыль в банке, собирая унион из двух запросов, и первый запрос НЕ учел concurrent платежку минусом, а второй учел плюсом, потому что не снапшот. А потом бахнул инсертом премию управляющему на основе этого. И че ты получил в итоге?

Даже если в вашем случае это оказалось приемлемо, это не делает это нормой. Под такое пишут либо клиенты, либо веб-интерфейсы.

Так мы и писали клиент, просто было требование заказчика, чтобы всё, что могла сделать клиентская морда, можно было бы сделать и с помощью psql.

иш чего захотел, учи мейкфайлы и не выпендривайся :)

Например, на которых можно сделать ORM не отдельной тулзой, как Hibernate в жабке (да и, наверное, почти любой ORM) а просто отдельной либой?

Это можно организовать практически в любом языке. Проблема только в скорости работы.

на лету сделать запись в БД соответствующих таблиц и функций

Может и может. Хз. Но это абсолютный быдлокод.

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

На кой чёрт описывать схему в xml, если можно сразу в SQL?

Во-первых ORM может быть не привязана к SQL (а если привязана, то такая ORM не нужна), во-вторых формальное, декларативное описание схемы сильно упрощает работу другим тулзам (тестирование, документирование и т.п.).

специально созданный для этого DDL

Который отличается от СУБД к СУБД.

В чем разница между использованием orm и не использованием тут? Ты можешь в рамках orm делать аналогичные запросы.

Зачем тогда нужна orm, если всё равно пишешь запросы руками в sql, а потом мапишь в какое-нибудь DTO?

Но вообще это фигня какая-то надуманная. Такие вещи надо хранить в каком-нить jsonfield

Нет. Ты опять ничего не понял. У тебя штук 20 параметров на объекте. Например есть лицевой у него какие-то свойства, услуги, есть на лицевом тариф со свойством «услуга», есть параметры тарифа. Тебе надо выбрать актуальные параметры по 10 тарифам или выбрать какую-то их часть. Тарифы с периодами актуальности, параметры с периодами актуальности. Ты правда хочешь хранить всё это говно на лицевом в json? Я нет. Да меня тот, кто у нас за DBA нахер пошлёт.