Здравствуйте, chaotic-kotik, Вы писали:

CK>Ну и весь type safety куда-то внезапно улетучивается и становится окончательно непонятно, с чего это вдруг мы используем какой-то EDSL.

При динамических запросах type-safety никуда не исчезает. Исчезает возможность сгенерировать код запроса во время компиляции, и то только для случаев где пространство динамического выбора большое.

EP>>Так в том и дело, "SELECT *" выдаст все колонки, что часто неэффективно, и в разных местах требуются разные проекции. В случае с DAL придётся либо плодить функции на каждый чих, либо вводить аналогичный EDSL.
CK>Ну это я для простоты через * написал, само собой так делать не нужно никогда.

Так а как ты предлагаешь делать? На каждый вариант проекции делать отдельную функцию в DAL? Постоянно модифицировать API DAL при необходимости нового поля?

EP>>А здесь ты точно также создаёшь фильтр на стороне пользователя, только в другой форме, но суть та же.
CK>Ну по сути да.

Так а в чём профит?

EP>>EDSL запросов по сути не особо отличается от того же Boost.Range например — практически такое же декларативное описание "запроса" к контейнерам. При этом вызовы Boost.Range ни в какой DAL не прячут.
CK>Ну так boost.range оперирует объектами в коде программы, SQL запрос оперирует данными в таблицах и по хорошему код не должен ничего знать про имена таблиц/полей, layout, join-s и тд.

Почему не должен знать? Зачем вводить новые слои на ровном месте? То есть что это даст по факту? И реально ли это необходимо?

CK>Для этого и нужен слой DAL. Иначе миграции схемы БД превратятся в сложные рефакторинги а это не есть хорошо.

За счёт типизации как раз проводить рефакторинги намного проще. Ошибки отлавливаются на этапе компиляции. В случае с текстовыми запросами точно также придётся проводить рефакторинги, только уже без помощи типизации.

CK>И ты ошибочно предполагаешь что построение запроса и конвертация результатов запроса — это то что нужно оптимизировать.

Во-первых, я это не предполагаю. Я лишь сказал что это возможно, в ответ на что получил сомнения в реализуемости. Собственно весь пример это лишь proof-of-concept.
Во-вторых, если у нас в любом случае есть compile-time EDSL запросов (а-ля sqlpp11) и можно достаточно просто (используя новые версии C++, Hana-style и т.п.) оптимизировать в том числе и эти моменты — то почему бы и нет.

CK>Zero overhead преобразование результатов тоже мало полезного дает

Это по сути несколько строчек кода, смотри map_result — так почему бы и нет?

CK>- некоторые БД отдают результаты в виде текста, некоторые предоставляют апи для доступа к данным результатов запросов вида `int getFieldAsInt(int field_index, int default_value)` и что ты вызовешь этот метод в своем EDSL, что класс в DAL вызовет его, разницы никакой.

Вот только в DAL ты будешь путаться в индексах, а EDSL это разрулит автоматом.
Более того, в той КСВ теме даже были заявления, что мол руками никто код с индексами и не пишет, вместо этого используют более медленные варианты (этим оправдывали сравнение EDSL варианта на индексах, против ручного варианта без индексов).