Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Почему? Вручную выписывать индексы, структуры, кое-как склеивать текст запроса, и к тому же ручную контролировать корректность всего этого. Ради чего?

Ради того чтобы не думать, а правильно ли эта языковая конструкция сгенерировала запрос. Или для того, чтобы любому было понятно что происходит в коде, без необходимости изучать еще одну библиотеку. Мало ли причин можно придумать. Причин за это я вижу не очень много. Корректность у тебя все равно контролируется в рантайме (т.к. самая частая проблема это не неправильно составленный запрос а изменение схемы, не отраженное в коде, а такое у тебя будет все равно отлавливаться во время исполнения).

CK>>Пытаюсь тут на простую схему намекать. Представь что у тебя есть таблица с документами (куча полей), есть таблица с метаданными, в метаданных описано в какой таблице хранятся документы,
EP>Это лишь один частный случай, в котором нужна динамика. EDSL запросов может работать в том числе и с динамикой, там где это необходимо — например как в sqlpp11.

Этот один частный случай я за последние лет наверное пять вижу вообще везде. Entity framework например похожим образом работает, или Hibernate. Реально с SQL-ем напрямую работают разве что всякие простые приложения, во всех сложных приложениях, с которыми мне приходилось работать, реализуется некий слой абстракции вокруг БД.

CK>>Далее, нам нужно завести новое поле — добавляем новую запись в таблицу метаданных, запускаем скрипт — скрипт делает миграцию (делает ALTER TABLE нужной таблице).
CK>>При старте сервис читает метаданные и после этого может работать с новой схемой. В этой архитектуре ничего рефактрить не нужно никогда вообще.

EP>Неверно. Не надо рефакторить только определённом наборе вариантов расширяемость которых заранее заложена в изначальную задачу. Причём в случае EDSL в этих же случаях точно также не нужно рефакторить.

Это почему не нужно будет? Тебе нужно будет новое поле добавить в структуру и модифицировать запросы, в зависимости от того, какая проекция там нужна.

Вот например есть табличка каталога оборудования и я добавил туда свойство `last_edit_time` которое содержит время последнего изменения. Теперь при выгрузке данных в xml мне нужно это поле читать, в UI контентщика мне нужно его показывать и фильтровать по нему, но в UI пользователя — не нужно показывать. Следовательно, два из трех запросов мне нужно изменить. Мало того, у этого поля должно быть имя в приложении (и в пользовательском и в сервисе), т.е. добавляя поле ты изменяешь сразу несколько артефактов. В сервисе появляется возможность обратиться к URL `/get_catalog_item?id=XXX&last_edit_time<7d-ago`, в UI контентщика появится возможность по этому полю искать и тд.

С общепринятым подходом ты просто добавишь запись в таблицу, в которой у тебя свойства каталога оборудования лежат, вот и все (может это будет SDL какой-нибудь, не обязательно табличка). В этой записи будет информация о том что поле доступно в таких то запросах, по нему можно фильтровать, его не нужно показывать пользователю но нужно показывать контентщику и тд. После миграции твой веб сервис будет принимать свойство last_edit_time (которое возможно будет по другому называться, имя поля в БД будет скрыто) и будет по нему фильтровать, в UI контентщика появится возможность выбрать это поле и отсортировать по нему или отфильтровать. Все это без необходимости изменять код вообще хоть где-нибудь. Конечно, если свойство добавляется в UI пользователя — возможно придется изменить верстку (или гуй) под это дело, но и то не всегда. Я видел несколько крупных веб проектов и одну систему документооборота предприятия, все они были построены таким образом.

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

EP>Если же произошло любое изменение вне этой расширяемости (например изменилась структура метаданных) — то нужно точно также рефакторить. При этом, опять таки, на основе текстовых запросов это всё делается труднее.

Структура метаданных это, как правило, либо готовый фреймверк, либо если это что-то самописное, то меняется все довольно просто, в одном месте.

EP>То есть ты говоришь мол есть документ с произвольным набором полей описанным метаданными, и на основе того что можно в него добавлять поля без рефакторинга, ты делаешь неверное обобщение "Ну можно ведь не рефактроирть"

Я описал упрощенную схему. В реальной жизни это скорее — есть модель данных, которая описана метаданными и в которую заложена расширяемость, поэтому ее можно легко расширять и это не требует изменений кода зачастую (если завязок на конкретные поля в коде сервиса/UI нет, что справедливо для большинства полей). Там конечно же бывает не одна табличка а куча таблиц, связей и тд.