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

EP>>>>Здесь не имеет значения, я вообще не утверждал что это супер практично. Это пример в контексте утверждения о невозможности, впрочем твоё передёргивание вполне ожидаемо
G>>>Ты сделал то, что делает sqlpp.
EP>>1. Насколько я помню в sqlpp11 не zero overhead, где-то выше даже был тест показывающий пусть и незначительный но overhead по сравнению с ручным запросом. Я же показал нулевые накладные расходы по сравнению с ручной версией — от этого в дальнейшем и можно отталкиваться.
G>Ты не те накладные расходы померил.

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

G>В твоем варианте накладные расходы от перекомпиляции непараметризованных запросов превысят любые экономии на склейке строк.

Какой ещё перекомпиляции?

G>>>Теперь покажи то, что делает linq.
EP>>Ну конечно, начинается, как я и говорил
G>Так ты не показал. Ключевая фича linq — конструирование запросов из кусков. У тебя нет такого конструирования, потому что у тебя даже дважды where написать нельзя.
G>Ты все пытаешься свести к статическим запросам,

Про динамичные я уже выше говорил с IT. Тебя что конкретно интересует?

G>а они ничем не лучше, чем написанные руками. Ты это показал. Только написанные руками понятнее.

А как же "главный козырь"?

IT>Ну и под конец главный козырь LINQ — type safety. Можете мне петь любые песни про любые тормоза, но это преимущество ни много ни мало переводит работу с БД на принципиально другой уровень.

G>>>Для затравки:
G>>>

G>>>IQueryable<Foo> F(IQueryable<Foo> q, int? v) => v.HasValue ? q.Where(x => x.value == v) : q
G>>>

EP>>Пример чего? Полностью динамических запросов или комбинаторики? Полностью динамические запросы есть в примерах sqlpp11.
EP>>...
G>Они не полностью динамические

Почему? Что по твоему мешает их сделать таковыми?

EP>>Во время компиляции генерируются восемь разных запросов, о чём я тебе и говорил более года назад

Автор: Evgeny.Panasyuk
Дата: 14.04.15

G>Ты опять пытаешься обсуждать что удобно тебе, а не что тебя просят.
G>Не нужно 8, нужно два — один с фильтром и параметром, второй без.
G>Функция, которая накладывает такой предикат должна работать с любым IQueryable<Foo>, независимо от того какие предикаты были на него наложены.

Причём тут любой "IQueryable"? В C++ другие техники.

EP>>Декомпозиция/композиция при конкретных типах есть.
EP>>Если ты чего-то не понимаешь, то не надо додумывать что тебе хочется и утверждать это как факт — лучше спроси про непонятные места
G>Нельзя написать from(t).where(x).where(y) чтобы это потом склеилось в нормальный запрос.

В первом примере нельзя так, как я посчитал это не нужным, ибо и так очевидно
А вот во втором примере как раз такая конструкция и поддерживается. Ты совсем не смотрел пример из сообщения на которое отвечаешь? Главное писать, да?

select foo.value, foo.id, foo.number from foo where number>12 and value>21 and id>32

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

EP>>>>Здесь не имеет значения, я вообще не утверждал что это супер практично. Это пример в контексте утверждения о невозможности, впрочем твоё передёргивание вполне ожидаемо
G>>>Ты сделал то, что делает sqlpp.
EP>>1. Насколько я помню в sqlpp11 не zero overhead, где-то выше даже был тест показывающий пусть и незначительный но overhead по сравнению с ручным запросом. Я же показал нулевые накладные расходы по сравнению с ручной версией — от этого в дальнейшем и можно отталкиваться.
G>Ты не те накладные расходы померил.

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

G>В твоем варианте накладные расходы от перекомпиляции непараметризованных запросов превысят любые экономии на склейке строк.

Какой ещё перекомпиляции?

G>>>Теперь покажи то, что делает linq.
EP>>Ну конечно, начинается, как я и говорил
G>Так ты не показал. Ключевая фича linq — конструирование запросов из кусков. У тебя нет такого конструирования, потому что у тебя даже дважды where написать нельзя.
G>Ты все пытаешься свести к статическим запросам,

Про динамичные я уже выше говорил с IT. Тебя что конкретно интересует?

G>а они ничем не лучше, чем написанные руками. Ты это показал. Только написанные руками понятнее.

А как же "главный козырь"?

IT>Ну и под конец главный козырь LINQ — type safety. Можете мне петь любые песни про любые тормоза, но это преимущество ни много ни мало переводит работу с БД на принципиально другой уровень.

G>>>Для затравки:
G>>>

G>>>IQueryable<Foo> F(IQueryable<Foo> q, int? v) => v.HasValue ? q.Where(x => x.value == v) : q
G>>>

EP>>Пример чего? Полностью динамических запросов или комбинаторики? Полностью динамические запросы есть в примерах sqlpp11.
EP>>...
G>Они не полностью динамические

Почему? Что по твоему мешает их сделать таковыми?

EP>>Во время компиляции генерируются восемь разных запросов, о чём я тебе и говорил более года назад

Автор: Evgeny.Panasyuk
Дата: 14.04.15

G>Ты опять пытаешься обсуждать что удобно тебе, а не что тебя просят.
G>Не нужно 8, нужно два — один с фильтром и параметром, второй без.
G>Функция, которая накладывает такой предикат должна работать с любым IQueryable<Foo>, независимо от того какие предикаты были на него наложены.

Причём тут любой "IQueryable"? В C++ другие техники.

EP>>Декомпозиция/композиция при конкретных типах есть.
EP>>Если ты чего-то не понимаешь, то не надо додумывать что тебе хочется и утверждать это как факт — лучше спроси про непонятные места
G>Нельзя написать from(t).where(x).where(y) чтобы это потом склеилось в нормальный запрос.

В первом примере нельзя, так как я посчитал это не нужным, ибо и так очевидно
А вот во втором примере как раз такая конструкция и поддерживается. Ты совсем не смотрел пример из сообщения на которое отвечаешь? Главное писать, да?

select foo.value, foo.id, foo.number from foo where number>12 and value>21 and id>32