Комментарии 15
Будет невероятно сложно поддерживать все реализации SQL из разных СУБД. По сути мы занимаемся полным копированием кода СУБД в C++. Идея очень крутая, но реализация сомнительно сложная. К тому же, проще и лучше сразу делать конструкторы запросов в виде функций и классов, как это делает sqlpp
Согласен, к примеру сейчас в проекте около 4 сотен таблиц и текущий подход превратит работу в ад.
А по sqlpp - время сборки проекта передаёт привет
Полностью согласен, покрывать и поддерживать весь sql - жизни не хватит. Статья о возможностях constexpr, на полноценный легковесный валидатор всего и вся надеяться не приходится. Сложность проверок и их количество ограничены адекватностью подхода, пока потенциальная польза перевешивает его недостатки.
По сути мы занимаемся полным копированием кода СУБД в C++
Ну можно же основные конструкции, которые покрывают 90% запросов. А оставшиеся 10% уже писать вручную без проверки.
Как пример. Есть ANTLR, в рамках него уже написаны грамматики под кучу БД. Например мы используем ANTLR postresql граматики чтобы валидировать все SQL запросы + flyway миграционные скрипты в своих проектах. Работает без запинки не первый год.
Static SQL переизобрели :)
Не, я мало что понимаю в С++, потому смотрел по диагонали. Но даже так - мне кажется, что применимость... ну скажем так, ограниченная. Во-первых, очень сильна привязка к конкретному диалекту SQL (порой изменения диалекта таковы, что даже изменение версии СУБД приведёт к ложным срабатываниям). Во-вторых, потенция ложных фэйлов, например, для СУБД с "мягкой" системой типов и автоприведением оных (а в большинстве СУБД это автоприведение хоть где-то, хоть в каких-то моментах, да встречается). В третьих, система совершенно не сможет работать с динамическим SQL, когда в формируемом запросе параметризованы имена объектов (скажем, имена таблиц или полей). Есть и в четвёртых, и в пятых... то есть, если я правильно понимаю, то код валидатора придётся каждый раз, для каждой программы или при каждом обновлении СУБД, создавать чуть ли не заново.
Во-первых, очень сильна привязка к конкретному диалекту SQL
Нужно делать как Entity Framework - свой язык запросов и трансляция в зависимости от СУБД + оптимизации.
Мне очень нравится sqlpp, примерно это и получилось
Да тоже не вдруг получится. То есть первую проблему вы снимете, да, а вторую и третью, увы, решить не получится - точнее, не получится сделать "если косяк, то программа вообще не соберётся". Как пример, MySQL и передача BIGINT значения в критерий с контекстом штампа времени - некоторые значения преобразуются корректно, некоторые приводят к ошибке преобразования, и на этапе компиляции это не получится установить в принципе. EF, кстати, это не ловит даже в рантайме - только по факту ошибки выполнения запроса..
inlineconsteval Schema DicxParser::Parse()
Вопрос знатокам C++ - зачем здесь inline? Это вроде строго constexpr контекст, для linkage он бесполезен, для встраивания вроде тоже. Очень интересно.
По большому счету он здесь не нужен, особенно в constexpr контексте. В целом избыточно, и уже давно игнорируется компиляторами — inlining решается оптимизатором. Если только как запасной парашют для ODR violation
Кроме того constexpr и consteval влечёт неявный inline - [9.2.6]
Нет, компиляторами ничего не игнорируется просто так, inline сейчас имеет просто другой смысл (выше написали про линковку), и к встраиванию не имеет никакого отношения. По-хорошему просто так его писать не нужно, иначе можно случайно замаскировать multiple definition error, который обычно выстрелит на линковке.
Миллениалы переизобрели sqlx, только с xml, cmake и python? Какой сейчас год?
Ошибки, которые не случились: C++ и compile‑time проверка SQL-запросов