Re[168]: Тормознутость и кривость linq. Compile-time EDSL DB - Компьютерные священные войны

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

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

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

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

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

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

Ну конечно, начинается, как я и говорил

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

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

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

#include "ctql.hpp"

#include <iostream>

DEFINE_TABLE
(
    foo,
    (int, id)
    (int, code)
    (double, value)
    (int, number)
);

auto conditional = [](bool condition, auto true_case, auto false_case)
{
    return [=](auto f)
    {
        return condition ? true_case(f) : false_case(f);
    };
};

auto conditional_where = [](bool condition, auto part1, auto true_filter, auto false_filter)
{
    return conditional
    (
        condition,
        [=](auto f){ return part1([=](auto part){ return f(part.where(true_filter)); }); },
        [=](auto f){ return part1([=](auto part){ return f(part.where(false_filter)); }); }
    );
};

auto dynamic()
{
    volatile bool flag1 = false, flag2 = true, flag3 = false;
    
    auto part1 = [](auto f){ return f(from(foo)); };

    auto part2 = conditional_where(flag1, part1, foo.number > 11_i, foo.number > 12_i);
    auto part3 = conditional_where(flag2, part2, foo.value > 21_i, foo.value > 22_i);
    auto part4 = conditional_where(flag3, part3, foo.id > 31_i, foo.id > 32_i);

    return part4;
}

int main()
{
    auto final = dynamic()([](auto part)
    {
        return part.select(foo.value, foo.id, foo.number).to_vector();
    });

    for(auto &&x : final)
    {
        using namespace std;
        cout << x.id << " " << x.value << " " << x.number << endl;
        // cout << x.code; // - compile error, because .code is not in projection
    }
}

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

Скрытый текст

    mov    esi, OFFSET FLAT:_ZN12string_valueIJLc115ELc101ELc108ELc101ELc99ELc116ELc32ELc102ELc111ELc111ELc46ELc118ELc97ELc108ELc117ELc101ELc44ELc32ELc102ELc111ELc111ELc46ELc105ELc100ELc44ELc32ELc102ELc111ELc111ELc46ELc110ELc117ELc109ELc98ELc101ELc114ELc32ELc102ELc114ELc111ELc109ELc32ELc102ELc111ELc111ELc32ELc119ELc104ELc101ELc114ELc101ELc32ELc110ELc117ELc109ELc98ELc101ELc114ELc62ELc49ELc32ELc97ELc110ELc100ELc32ELc118ELc97ELc108ELc117ELc101ELc62ELc50ELc49ELc32ELc97ELc110ELc100ELc32ELc105ELc100ELc62ELc51ELc49EEE5valueE
    mov    esi, OFFSET FLAT:_ZN12string_valueIJLc115ELc101ELc108ELc101ELc99ELc116ELc32ELc102ELc111ELc111ELc46ELc118ELc97ELc108ELc117ELc101ELc44ELc32ELc102ELc111ELc111ELc46ELc105ELc100ELc44ELc32ELc102ELc111ELc111ELc46ELc110ELc117ELc109ELc98ELc101ELc114ELc32ELc102ELc114ELc111ELc109ELc32ELc102ELc111ELc111ELc32ELc119ELc104ELc101ELc114ELc101ELc32ELc110ELc117ELc109ELc98ELc101ELc114ELc62ELc50ELc32ELc97ELc110ELc100ELc32ELc118ELc97ELc108ELc117ELc101ELc62ELc50ELc49ELc32ELc97ELc110ELc100ELc32ELc105ELc100ELc62ELc51ELc49EEE5valueE
    mov    esi, OFFSET FLAT:_ZN12string_valueIJLc115ELc101ELc108ELc101ELc99ELc116ELc32ELc102ELc111ELc111ELc46ELc118ELc97ELc108ELc117ELc101ELc44ELc32ELc102ELc111ELc111ELc46ELc105ELc100ELc44ELc32ELc102ELc111ELc111ELc46ELc110ELc117ELc109ELc98ELc101ELc114ELc32ELc102ELc114ELc111ELc109ELc32ELc102ELc111ELc111ELc32ELc119ELc104ELc101ELc114ELc101ELc32ELc110ELc117ELc109ELc98ELc101ELc114ELc62ELc49ELc32ELc97ELc110ELc100ELc32ELc118ELc97ELc108ELc117ELc101ELc62ELc50ELc50ELc32ELc97ELc110ELc100ELc32ELc105ELc100ELc62ELc51ELc49EEE5valueE
    mov    esi, OFFSET FLAT:_ZN12string_valueIJLc115ELc101ELc108ELc101ELc99ELc116ELc32ELc102ELc111ELc111ELc46ELc118ELc97ELc108ELc117ELc101ELc44ELc32ELc102ELc111ELc111ELc46ELc105ELc100ELc44ELc32ELc102ELc111ELc111ELc46ELc110ELc117ELc109ELc98ELc101ELc114ELc32ELc102ELc114ELc111ELc109ELc32ELc102ELc111ELc111ELc32ELc119ELc104ELc101ELc114ELc101ELc32ELc110ELc117ELc109ELc98ELc101ELc114ELc62ELc50ELc32ELc97ELc110ELc100ELc32ELc118ELc97ELc108ELc117ELc101ELc62ELc50ELc50ELc32ELc97ELc110ELc100ELc32ELc105ELc100ELc62ELc51ELc49EEE5valueE
    mov    esi, OFFSET FLAT:_ZN12string_valueIJLc115ELc101ELc108ELc101ELc99ELc116ELc32ELc102ELc111ELc111ELc46ELc118ELc97ELc108ELc117ELc101ELc44ELc32ELc102ELc111ELc111ELc46ELc105ELc100ELc44ELc32ELc102ELc111ELc111ELc46ELc110ELc117ELc109ELc98ELc101ELc114ELc32ELc102ELc114ELc111ELc109ELc32ELc102ELc111ELc111ELc32ELc119ELc104ELc101ELc114ELc101ELc32ELc110ELc117ELc109ELc98ELc101ELc114ELc62ELc49ELc32ELc97ELc110ELc100ELc32ELc118ELc97ELc108ELc117ELc101ELc62ELc50ELc49ELc32ELc97ELc110ELc100ELc32ELc105ELc100ELc62ELc51ELc50EEE5valueE
    mov    esi, OFFSET FLAT:_ZN12string_valueIJLc115ELc101ELc108ELc101ELc99ELc116ELc32ELc102ELc111ELc111ELc46ELc118ELc97ELc108ELc117ELc101ELc44ELc32ELc102ELc111ELc111ELc46ELc105ELc100ELc44ELc32ELc102ELc111ELc111ELc46ELc110ELc117ELc109ELc98ELc101ELc114ELc32ELc102ELc114ELc111ELc109ELc32ELc102ELc111ELc111ELc32ELc119ELc104ELc101ELc114ELc101ELc32ELc110ELc117ELc109ELc98ELc101ELc114ELc62ELc50ELc32ELc97ELc110ELc100ELc32ELc118ELc97ELc108ELc117ELc101ELc62ELc50ELc49ELc32ELc97ELc110ELc100ELc32ELc105ELc100ELc62ELc51ELc50EEE5valueE
    mov    esi, OFFSET FLAT:_ZN12string_valueIJLc115ELc101ELc108ELc101ELc99ELc116ELc32ELc102ELc111ELc111ELc46ELc118ELc97ELc108ELc117ELc101ELc44ELc32ELc102ELc111ELc111ELc46ELc105ELc100ELc44ELc32ELc102ELc111ELc111ELc46ELc110ELc117ELc109ELc98ELc101ELc114ELc32ELc102ELc114ELc111ELc109ELc32ELc102ELc111ELc111ELc32ELc119ELc104ELc101ELc114ELc101ELc32ELc110ELc117ELc109ELc98ELc101ELc114ELc62ELc49ELc32ELc97ELc110ELc100ELc32ELc118ELc97ELc108ELc117ELc101ELc62ELc50ELc50ELc32ELc97ELc110ELc100ELc32ELc105ELc100ELc62ELc51ELc50EEE5valueE
    mov    esi, OFFSET FLAT:_ZN12string_valueIJLc115ELc101ELc108ELc101ELc99ELc116ELc32ELc102ELc111ELc111ELc46ELc118ELc97ELc108ELc117ELc101ELc44ELc32ELc102ELc111ELc111ELc46ELc105ELc100ELc44ELc32ELc102ELc111ELc111ELc46ELc110ELc117ELc109ELc98ELc101ELc114ELc32ELc102ELc114ELc111ELc109ELc32ELc102ELc111ELc111ELc32ELc119ELc104ELc101ELc114ELc101ELc32ELc110ELc117ELc109ELc98ELc101ELc114ELc62ELc50ELc32ELc97ELc110ELc100ELc32ELc118ELc97ELc108ELc117ELc101ELc62ELc50ELc50ELc32ELc97ELc110ELc100ELc32ELc105ELc100ELc62ELc51ELc50EEE5valueE

G>1) Три разных типа для select, where и from не подойдут, не будет никакой композиции

Декомпозиция/композиция при конкретных типах есть.
Если ты чего-то не понимаешь, то не надо додумывать что тебе хочется и утверждать это как факт — лучше спроси про непонятные места

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

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

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

Кому нужно? Что нового это даст в рамках данной дискуссии?

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

EP>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead

A>Не напрягает, что SQL текстовой? Это ж сколько ценных тактиков на сервере тратится на парсинг! А еще СУБД статистику ведет, план запроса подбирает и многое другое сомнительное делает, что, в теории, можно было бы в компайл-тайм задать или вычислить — вот тут и надо бы пооптимизировать!

И вообще не понятно к чему здесь сарказм. Потребность в быстрых запросах есть, например StackExchange запилили dapper (оставим в стороне вопрос на сколько у них хорошо это получилось), тот же IT оптимизирует linq2db — мэппинг, кэш запросов, делает benchmark'и и т.п. — если бы это всё не требовалось, то ведь и делалось бы жеж

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

EP>И вообще не понятно к чему здесь сарказм. Потребность в быстрых запросах есть, например StackExchange запилили dapper (оставим в стороне вопрос на сколько у них хорошо это получилось), тот же IT оптимизирует linq2db — мэппинг, кэш запросов, делает benchmark'и и т.п. — если бы это всё не требовалось, то ведь и делалось бы жеж

Видишь ли, есть существенное отличие между "потребность в быстрых запросах есть" и "это решение достаточно феерично своей кривизной".

Здравствуйте, Ночной Смотрящий, Вы писали:

EP>>И вообще не понятно к чему здесь сарказм. Потребность в быстрых запросах есть, например StackExchange запилили dapper (оставим в стороне вопрос на сколько у них хорошо это получилось), тот же IT оптимизирует linq2db — мэппинг, кэш запросов, делает benchmark'и и т.п. — если бы это всё не требовалось, то ведь и делалось бы жеж

НС>Видишь ли, есть существенное отличие между "потребность в быстрых запросах есть" и "это решение достаточно феерично своей кривизной".

Я то вижу, вот только первая фраза моя, а вторая нет, и даже то сообщение никак не оценивал

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

I>>То есть, ты решил, что gangjustas, познакомившись с edsl в sqlpp,

EP>Судя по тому что он пишет, он и не знакомился

Наоборот: "Ты сделал то, что делает sqlpp." @ gangjustas

I>>пришел к выводу, что реализовать еще один edsl принципиально невозможно ?

EP>

G>>>На практике никто такое не сделал, значит невозможно.

1 Гипотетическая возможность или наколеночные поделки никого не интересуют.
2 Нужен глобально доступный концепт, его дает как раз языковая фича или стандарт. Примером является скажем либа stl.

STL является доказательством того, что этот подход реализуем и используется глобально. А вот с БД edsl это не так.

На практике __никто__ не написал глобально используемую либу для БД на основе Expression Tree (edsl как у тебя).
Следвательно, доказательства возможности не было предоставлено.

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

EP>>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead

I>>Сколько ты сэкономишь на фоне издержек сетевого стека ?

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

Правильно понимаю, твой восторг был вызван не практической ценностью решения, а всего лишь победой над очередной языковой фичей ?

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

I>>>То есть, ты решил, что gangjustas, познакомившись с edsl в sqlpp,
EP>>Судя по тому что он пишет, он и не знакомился

I>Наоборот: "Ты сделал то, что делает sqlpp." @ gangjustas

"Так и ты так говори"

Вот конкретно его слова:

G>>Это api для более-менее типизированного построения примитивных запросов. Он не может никаким образом получить два разных запроса из одного и того же куска кода. Даже теоретически.
EP>Это ещё почему? Например у него есть коннектор в БД, и к обычным контейнерам — один и тот же запрос может выполнять совершенно разные веши

Вывод — с sqlpp11 он не знакомился

I>>>пришел к выводу, что реализовать еще один edsl принципиально невозможно ?

EP>>

G>>>>На практике никто такое не сделал, значит невозможно.

I>1 Гипотетическая возможность или наколеночные поделки никого не интересуют.
I>2 Нужен глобально доступный концепт, его дает как раз языковая фича или стандарт. Примером является скажем либа stl.

Кому нужен? Он просил конкретный пример — я привёл. Ты думаешь он ожидал что я за вечер накидаю "глобально доступный концепт"?

I>STL является доказательством того, что этот подход реализуем и используется глобально. А вот с БД edsl это не так.
I>На практике __никто__ не написал глобально используемую либу для БД на основе Expression Tree (edsl как у тебя).

Смотри ODB, там те же самые expressions, вот список клиентов.

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

A>>Не напрягает, что SQL текстовой? Это ж сколько ценных тактиков на сервере тратится на парсинг! А еще СУБД статистику ведет, план запроса подбирает и многое другое сомнительное делает, что, в теории, можно было бы в компайл-тайм задать или вычислить — вот тут и надо бы пооптимизировать!

EP>И вообще не понятно к чему здесь сарказм. Потребность в быстрых запросах есть, например StackExchange запилили dapper

Быстрые запросы это про узкое место, а не zero overhead. Узкое место в порядке убывания важности:
1 внешний http + кеширование
2 балансирование нагрузки, унутренний сетевой стек
3 файловая система сервера БД
4 сеть между сервером и БД

Твои темплейты дадут эффект только после того, как все эти вещи будут вылизаны до идеального состояния.

То есть, для профита не должно быть ни одного из барьеров выше. Фактически — запрос к in-memory-DB вне сетевого стека. Самое интересное, что в этом случае применимы принципиально другие механизмы работы с данными. То есть, zero overhead снова всего лишь одна из возможностей.

Вот это понятно или есть возражения ?

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

EP>"Так и ты так говори"

EP>Вот конкретно его слова:
EP>

G>>>Это api для более-менее типизированного построения примитивных запросов. Он не может никаким образом получить два разных запроса из одного и того же куска кода. Даже теоретически.
EP>>Это ещё почему? Например у него есть коннектор в БД, и к обычным контейнерам — один и тот же запрос может выполнять совершенно разные веши

Вывод — с sqlpp11 он не знакомился

Теоретически — не может. Гипотетически — может

1 Трансляция sql-sql вносит неопределенность и которая в sqlpp принципиально не устранена.
2 Динамика никуда не делась. см пример про фильтры.

I>>1 Гипотетическая возможность или наколеночные поделки никого не интересуют.
I>>2 Нужен глобально доступный концепт, его дает как раз языковая фича или стандарт. Примером является скажем либа stl.

EP>Кому нужен? Он просил конкретный пример — я привёл. Ты думаешь он ожидал что я за вечер накидаю "глобально доступный концепт"?

Глобально доступный концепт — языковая фича или стандарт. Скажем stl — именно такой стандарт, либа реализована на вполне конкретных языковых фичах.

I>>STL является доказательством того, что этот подход реализуем и используется глобально. А вот с БД edsl это не так.
I>>На практике __никто__ не написал глобально используемую либу для БД на основе Expression Tree (edsl как у тебя).

EP>Смотри ODB, там те же самые expressions, вот список клиентов.

Капля в море. В норме на с++ используется целый зоопарк подходов даже в рамках конкретного проекта. А вот linq это и языковая фича и стандарт для всей индустрии.

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

EP>>>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead

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

I>Правильно понимаю, твой восторг был вызван не практической ценностью решения, а всего лишь победой над очередной языковой фичей ?

Как я уже неоднократно заявлял, с СУБД не работаю — не встречаются такие задачи, поэтому для меня вообще вся эта тема не имеет особой практической ценности.
Никаких побед над языковыми фичами не было, подобные штуки но в других контекстах я уже реализовал и знал все соответствующие технические аспекты, о чём и заявлял ранее.

Восторг же связан с тем что я получил ровно то что и что и планировал изначально — идентичный ассемблерный код, ибо это самая красноречивая манифестация zero overhead, позволяющая на корню отсечь все кривотолки. Компилятор например мог переставить некоторые инструкции местами и т.п., что вовсе и не означало бы overhead, но уже получилось бы не так эффектно.

Помимо примера побочным образом запилил экспорт из Org-Mode в формат RSDN, и теперь мне подобные примеры намного проще оформлять, актуализировать результаты выполнения, экспортировать в другие форматы (HTML, Markdown, LaTeX, PDF, ASCII, etc) и т.п., что также порадовало

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

I>>>>>То есть, ты решил, что gangjustas, познакомившись с edsl в sqlpp,
EP>>>>Судя по тому что он пишет, он и не знакомился

I>>>Наоборот: "Ты сделал то, что делает sqlpp." @ gangjustas
EP>>"Так и ты так говори"

EP>>Вот конкретно его слова:
EP>>

G>>>>Это api для более-менее типизированного построения примитивных запросов. Он не может никаким образом получить два разных запроса из одного и того же куска кода. Даже теоретически.
EP>>>Это ещё почему? Например у него есть коннектор в БД, и к обычным контейнерам — один и тот же запрос может выполнять совершенно разные веши

Вывод — с sqlpp11 он не знакомился

I>Теоретически — не может. Гипотетически — может

Какой гибкий позвоночник.

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

I>>>>Наоборот: "Ты сделал то, что делает sqlpp." @ gangjustas
EP>>>"Так и ты так говори"

EP>>>Вот конкретно его слова:
EP>>>

G>>>>>Это api для более-менее типизированного построения примитивных запросов. Он не может никаким образом получить два разных запроса из одного и того же куска кода. Даже теоретически.
EP>>>>Это ещё почему? Например у него есть коннектор в БД, и к обычным контейнерам — один и тот же запрос может выполнять совершенно разные веши

Вывод — с sqlpp11 он не знакомился

I>>Теоретически — не может. Гипотетически — может

EP>Какой гибкий позвоночник.

Теория подразумевает проверяемый эксперимент. Его до сих пор нет. Так что остаётся гипотетическая возможность.

Здравствуйте, 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>Во время компиляции генерируются восемь разных запросов, о чём я тебе и говорил более года назад
Ты опять пытаешься обсуждать что удобно тебе, а не что тебя просят.
Не нужно 8, нужно два — один с фильтром и параметром, второй без.
Функция, которая накладывает такой предикат должна работать с любым IQueryable<Foo>, независимо от того какие предикаты были на него наложены.

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

Здравствуйте, 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>>Во время компиляции генерируются восемь разных запросов, о чём я тебе и говорил более года назад
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

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

EP>Как я уже неоднократно заявлял, с СУБД не работаю

Но споришь с теми, кто с ними работает. Причем ладно бы о языковых фичах, но ты берешься выдавать экспертные оценки по количеству запросов, а это на фоне полного незнания тобой предмета полнейший

Здравствуйте, Ночной Смотрящий, Вы писали:

EP>>Как я уже неоднократно заявлял, с СУБД не работаю
НС>Но споришь с теми, кто с ними работает.

И что из этого? Это какое-то табу?

НС>Причем ладно бы о языковых фичах, но ты берешься выдавать экспертные оценки по количеству запросов, а это на фоне полного незнания тобой предмета полнейший

.

Давай пруф-линк. Я вообще-то как раз спрашивал мнение о количестве запросов.

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

EP>И вообще не понятно к чему здесь сарказм. Потребность в быстрых запросах есть, например StackExchange запилили dapper (оставим в стороне вопрос на сколько у них хорошо это получилось)

C dapper полный контроль над формируемым sql, нет change tracking с attach\detach геморроем.
В linq2db, например, IT добавил много всякостей, позволяющих управлять генерируемым sql — можно хинты заковыривать, можно специфичные субд функции вызывать — и все без необходимости отказываться от удобств linq. Ну и change tracking тоже отсутствует.

https://samsaffron.com/archive/2011/03/30/How+I+learned+to+stop+worrying+and+write+my+own+ORM
http://stackoverflow.com/questions/5374165/entityref-and-compiled-linq-plans

Судя по всему, у них была проблема N+1 с ленивой загрузкой. Причем в linq2sql в EntityRef.Entity на каждый вызов делалась динамическая компиляция кода. Вероятно, вот это место: https://github.com/Microsoft/referencesource/blob/master/System.Data.Linq/SqlClient/Reader/ObjectReaderCompiler.cs#L206

Заменив ORM на свою микро-ORM (не поддерживающую ленивую загрузку) они пофиксили проблему N+1. Последнее, на сколько понимаю, и дало основной профит. Не факт, что для этого требовалось менять ORM, на мой взгляд.

EP>, тот же IT оптимизирует linq2db — мэппинг, кэш запросов, делает benchmark'и и т.п. — если бы это всё не требовалось, то ведь и делалось бы жеж

Да, IT перфекционист. Еще бы асинхронщину реализовал честную — совсем круто было бы.

	От:	Evgeny.Panasyuk
	Дата:	06.07.16 11:07
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	06.07.16 11:11
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	06.07.16 11:17
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	06.07.16 11:47
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	06.07.16 13:01
	Оценка:

	От:	Ночной Смотрящий
	Дата:	06.07.16 14:35
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	06.07.16 16:23
Оценка:	+1