Информация об изменениях

Сообщение Re[147]: Тормознутость и кривость linq. Compile-time EDSL DB от 06.07.2016 16:23

Изменено 06.07.2016 16:24 gandjustas

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

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


EP>>>Здесь не имеет значения, я вообще не утверждал что это супер практично. Это пример в контексте утверждения о невозможности, впрочем твоё передёргивание вполне ожидаемо

G>>Ты сделал то, что делает sqlpp.

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

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

EP>2. Я показал ровно то что ты просил

EP>

G>>>>Фильтры и проекции, с джоинами потом разберемся


G>>Теперь покажи то, что делает linq.

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

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


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

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


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

EP>...
Они не полностью динамические

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

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


EP>Декомпозиция/композиция при конкретных типах есть.

EP>Если ты чего-то не понимаешь, то не надо додумывать что тебе хочется и утверждать это как факт — лучше спроси про непонятные места
Нельзщя написать

G>>2) Запрос должен быть с параметрами


EP>И что от этого принципиально поменяется? Ну добавиться в запрос закорючка, а в db новый аргумент


G>>3) Нужно поддерживать nullable


EP>Кому нужно? Что нового это даст в рамках данной дискуссии?
Re[147]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Здесь не имеет значения, я вообще не утверждал что это супер практично. Это пример в контексте утверждения о невозможности, впрочем твоё передёргивание вполне ожидаемо

G>>Ты сделал то, что делает sqlpp.

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

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

EP>2. Я показал ровно то что ты просил

EP>

G>>>>Фильтры и проекции, с джоинами потом разберемся


G>>Теперь покажи то, что делает linq.

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

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


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

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


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

EP>...
Они не полностью динамические

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

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


EP>Декомпозиция/композиция при конкретных типах есть.

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