Re[55]: EntityFramework - тормоз
От: alex_public  
Дата: 24.04.15 14:31
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Плохо. Но в гугле то тебя не забанили? Первая же ссылка ведет на MSDN — https://msdn.microsoft.com/en-us/library/vstudio/bb896297(v=vs.100).aspx


Хм, в принципе выглядит не плохо. Правда ручные перечисления типов (а их точно нельзя выводить автоматически?) несколько не эстетичны, но в принципе терпимо.
Re[49]: EntityFramework - тормоз
От: Mamut Швеция http://dmitriid.com
Дата: 24.04.15 14:36
Оценка:
S>Это оттого, что вы путаете причину со следствием. Фанаты вашего подхода просто оставляют UI-разработчика наедине с единственной функцией GetUser(int userId).

Хе-хе. Мы сначала хотели так фанатично пилить наш REST API. Типа возвращаются только id и ссылки на следующие данные. Так появился media-type application/vnd.something.order-v1+json

А потом наступила реальность В итоге этот медиа тип не используется, от слова вообще, а используются два других: application/vnd.something.aggregated-order-v1+json и application/pdf

В aggregated order запихано всё


dmitriid.comGitHubLinkedIn
Re[49]: EntityFramework - тормоз
От: alex_public  
Дата: 24.04.15 14:56
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

_>> В каждом случае можно подобрать оптимальное.

НС>Какое?

Сформулируй конкретный случай и получишь конкретное оптимальное решение.

_>> Но мне чаще всего попадались случаи, когда удобнее всего забирать пользователя целиком (прямо при проверке id сессии).

НС>Ну вот прям на этом сайте — идем в профиль и видим один набор полей пользователя. Щелкаем по закладкам — получаем другие поля. Смотрим сообщения — там третьи поля. Список сообщений или оценок — там опять отдельный набор.

Ты не путай запрос одного пользователя и запрос некого списка. )

_>>Я думаю вполне понятно, как такой API будет использоваться из прикладного кода.

НС>С Add все понятно. Там и в линке IQueryable скорее всего не будет. Что насчет Select то?

Эээ что? ) Вообще то это я спрашивал тебя как будет выглядеть в прикладном коде решение указанной задачи на linq.

НС>Нет, недостаточно. Потому что на практике прежде всего presentation layer определяет вид запроса, причем на каждой форме/страничке камк правило запросы уникальны. Так что же получается? Выборку практически всех данных делает твой специалист, html рисуют верстальщики, скрипты пишут тоже специальные люди. Так кому твое API тогда предназначено? Ненужной обезъянке, втыкающей в контроллер проброс вызова в твое возжеланное API?


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

_>>Ну вот если кто-то говорит, что "поддержка нескольких РСУБД — это редчайшее явление", то это просто автоматический диагноз, что человек вообще не в курсе веб-разработки.

НС>Ну ну. Много дон веб-разработал то? А то чета гложут меня смутные сомнения.

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

Кстати, если вспомнить статистику из таких анализов, то можно сделать очень забавный вывод, в контексте нашей дискуссии. Как я уже сказал, большинство веб-движков умеют работать с несколькими СУБД. Но есть и такие, которые действительно умеют только одну. Только вот самое интересное заключается в том, что это за СУБД такая: практически всегда это та самая mysql! Да, да, та самая, которую в этой темке так ругали. Т.е. если бы это была какая-нибудь Oracle с набором уникальных возможностей, то можно было бы сделать вывод, что переносимость невозможна из-за использования этих возможностей. Но тут у нас mysql... Так что очевидно, что авторы просто не осилили написание слоя абстракции, посчитав что и работы с одной такой БД хватит им для нормальной конкуренции (это они зря...). Но технических проблем (о которых в данной темке заявляли некоторые "специалисты") очевидно нет.
Re[49]: EntityFramework - тормоз
От: alex_public  
Дата: 24.04.15 15:04
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Это оттого, что вы путаете причину со следствием. Фанаты вашего подхода просто оставляют UI-разработчика наедине с единственной функцией GetUser(int userId). У него тупо нет другого выбора, кроме как есть тот API, который ему дали. Потом начинаются костыли типа "загрузка пользователя у нас дорогая, поэтому пусть делается один раз в сессию", и проблемы типа "если пользователь сменил ник в другой сессии, то ему надо перелониться в этой" и т.п.


Вообще то уже выше по темке было чётко указано (причём не только мною), что GetUser(int userId) не может быть дорогой в любом вменяемом (если не хранить какие-то жирные blob'ы там) случае.

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


В большинстве приложений (если это не что-то типа phpmyadmin) набор запросов является мало изменяемой сущностью.
Re[39]: EntityFramework - тормоз
От: alex_public  
Дата: 24.04.15 15:20
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>2. более сложный вопрос: а за счёт чего и как мы планируем порождать типы и контролировать корректность статически?

S>Попробуйте написать простейший запрос типа "покажи мне всех менеджеров, которые продали больше среднего в своих отделах в прошлом году". На sql это пишется тривиально:
S>
S>WITH 
S>  SalesYearlyTotals (SalesPersonID, TotalSales, SalesYear)
S>AS
S>(
S>    SELECT SalesPersonID, SUM(TotalDue) AS TotalSales, YEAR(OrderDate) AS SalesYear
S>    FROM Sales.SalesOrderHeader
S>    WHERE SalesPersonID IS NOT NULL
S>       GROUP BY SalesPersonID, YEAR(OrderDate)
S>),
S>  SalesYearlyAverages
S>AS
S>(
S>    SELECT SalesBranchID, AVG(TotalSales) AS AverageSales, SalesYear
S>    FROM SalesYearlyTotals inner join SalesPersons on SalesYearlyTotals.SalesPersonId = SalesPersons.Id
S>    GROUP BY SalesBranchID, SalesYear
S>)
S>SELECT SalesPersonId 
S>  FROM SalesYearlyTotals 
S>  INNER JOIN SalesPersons on SalesYearlyTotals.SalesPersonID = SalesPersons.SalesPersonID
S>  INNER JOIN SalesYearlyAverages on SalesPersons.SalesBranchID = SalesYearlyAverages.SalesBranchID AND SalesYearlyTotals.SalesYear = SalesYearlyAverages.SalesYear
S>  where SalesYearlyTotals.TotalSales >= SalesYearlyAverages.AverageSales
S>

S>Linq позволит мне разнести этапы определения CTE и сборки запроса, отчего код сильно выиграет в читаемости и редактируемости. При этом шаг вправо-влево будет отслеживаться компилятором, т.к. в процессе сборки дерева выводятся типы промежуточных результатов и всё проверяется. На первый взгляд, sqlpp не предлагает ничего интереснее констант для имён таблиц и полей.

Очень непрофессиональный первый взгляд. Тем более, что в этой теме уже были ссылки на примеры, демонстрирующие все техники, необходимые для реализации примера выше. Ну если провести аналогию от примеров из библиотеки к данному так сложно, то я могу помочь:
Sales::Person p; Sales::Order o;
auto y=select(o.person, sum(o.total).as(year_sales), o.year).from(o).where(is_not_null(o.person)).group_by(o.person, o.year).as(sqlpp::alias::y);
auto a=select(p.branch, avg(y.year_sales).as(branch_avg), y.year).from(p.join(y).on(p.id==y.person)).where(true).group_by(p.branch, y.year).as(sqlpp::alias::a);
auto q=select(p.id).from(p.join(y).on(p.id==y.person).join(a).on(p.branch==a.branch)).where(y.year_sales>a.branch_avg);

Это компилируемый код, если что. )))
Re[39]: EntityFramework - тормоз
От: Evgeny.Panasyuk Россия  
Дата: 24.04.15 15:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>>Ок, я понял. Обстоят чуть хуже, чем никак:

S>>>
S>>>    auto x = select(apples.appleId, oranges.orangeId); // WTF is x???
S>>>

EP>>Это же простой пример не претендующий на полноту. При желании можно получить например такой синтаксис:
S>1. простой вопрос: так что же всё-таки есть в этом sqlpp, кроме добрых намерений? А то вот некоторые по соседству смело утверждают, что есть прямо таки всё и из коробки. А вы пишете про "при желании"...

Я показываю не sqlpp11, а технику которая может использоваться для создания структуры с необходимым набором полей (а не просто безликий котреж), причём наполняя её в зависимости от каких-либо compile-time условий.

S>Я, не имея С++ компилятора под рукой, склоняюсь к тому, что sqlpp11 умеет проверять только простейшие сценарии.


sqlpp11 я знаю только по нескольким примерам, умеет ли он или нет "сложные" сценарии — ручаться не могу. Тем не менее, если интересны какие-то конкретные моменты sqlpp11 — можем здесь разобрать.

S>2. более сложный вопрос: а за счёт чего и как мы планируем порождать типы и контролировать корректность статически?


За счёт того что у нас во время компиляции известны: структура таблиц, связи между ними, дерево выражения запроса — и для обработки этого есть язык времени компиляции полный по Тьюрингу.

S>Попробуйте написать простейший запрос типа "покажи мне всех менеджеров, которые продали больше среднего в своих отделах в прошлом году". На sql это пишется тривиально:


На чём? На sqlpp11 или показать абстрактный вариант compile-time EDSL?

S>Linq позволит мне разнести этапы определения CTE и сборки запроса, отчего код сильно выиграет в читаемости и редактируемости.


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

Пример:
// Terminal symbols:
struct Select {} select;
struct Where {} where;

// Nonterminal:
template<typename Left, typename Right> struct Pipeline {};

template<typename T, typename U>
auto operator|(T, U)
{
    return Pipeline<T, U>{};
}

// Utility for print type at compile time:
template<typename T> void type_is(T);

int main()
{
    // Create expression tree by parts, in different expressions:
    // 1:
    auto q1 = select | where;
    // 2:
    auto q2 = q1 | select;
    // Print type of q2:
    type_is(q2);
}
Результат:
undefined reference to `void type_is<Pipeline<Pipeline<Select, Where>, Select> >(Pipeline<Pipeline<Select, Where>, Select>)'

Жирным выделен тип. Этот тип можно обрабатывать во время компиляции.
Например можем запретить построение выражения вида * | where | select | where | *:
// Process expression tree:
template<typename _>
struct CheckGrammar
{
    using type = bool;
};

template<typename Left, typename Right>
struct CheckGrammar<Pipeline<Left, Right>>
{
    using type = typename CheckGrammar<Left>::type; // Recurse to left sub-tree
};

template<typename _>
struct CheckGrammar
<
    Pipeline<Pipeline<Pipeline<_, Where>, Select>, Where> // Pattern matching
>
{
    using type = typename _::error_in_grammar_after;
};

template<typename T, typename U>
auto operator|(T, U)
{
    auto result = Pipeline<T, U>{};
    using run = typename CheckGrammar<decltype(result)>::type; // Run grammar check at compile-time
    return result;
}

int main()
{
    auto q1 = where | select | select; // OK
    auto q2 = q1 | where; // OK
    auto q3 = q2 | select | where; // ERROR
}
Вывод компилятора:
  Скрытый текст
main.cpp:31:30: error: no type named 'error_in_grammar_after' in 'Pipeline<Pipeline<Where, Select>, Select>'
    using type = typename _::error_in_grammar_after;
                 ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

main.cpp:38:26: note: in instantiation of template class 'CheckGrammar<Pipeline<Pipeline<Pipeline<Pipeline<Pipeline<Where, Select>, Select>, Where>, Select>, Where> >' requested here
    using run = typename CheckGrammar<decltype(result)>::type; // Run grammar check at compile-time
                         ^

main.cpp:46:27: note: in instantiation of function template specialization 'operator|<Pipeline<Pipeline<Pipeline<Pipeline<Where, Select>, Select>, Where>, Select>, Where>' requested here
    auto q3 = q2 | select | where; // ERROR

Подобное дерево можно обрабатывать как угодно. Результатом compile-time обработки, опять таки полной по Тьюрингу, может быть строка запроса.
Можно расширить пример полями из предыдущего примера, и наполнять ими struct в зависимости от структуры дерева выражения, отображать на них результат запроса и т.д. и т.п.

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


Это тоже не проблема.

S>На первый взгляд, sqlpp не предлагает ничего интереснее констант для имён таблиц и полей.


В документации написано что есть под-запросы.
При этом повторюсь:

http://rsdn.ru/forum/flame.comp/6014725.1


EP>Изначально речь шла про принципиальную возможность. А возможно это не только в C++, но и например в D или Nemerle.
EP>Что же касается конкретного примера — я с СУБД вообще не работаю. Для создания полного примера мне придётся разбираться с одной из упомянутых выше библиотек — на первый взгляд то о чём я говорю там вполне реализуемо, но могут быть некоторые детали которые будут препятствовать реализации, что впрочем никак не будет означать принципиальную невозможность, и соответственно к изначальному тезису не имеет отношения.

EP>Если же есть сомнения в принципиальной реализуемости — то готов ответить на конкретные вопросы.

Отредактировано 24.04.2015 15:35 Evgeny.Panasyuk . Предыдущая версия . Еще …
Отредактировано 24.04.2015 15:31 Evgeny.Panasyuk . Предыдущая версия .
Re[56]: EntityFramework - тормоз
От: Ночной Смотрящий Россия  
Дата: 24.04.15 18:42
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Правда ручные перечисления типов (а их точно нельзя выводить автоматически?)


В полях — нельзя. Если воткнуть локально через замыкания — можно.
Re[50]: EntityFramework - тормоз
От: Ночной Смотрящий Россия  
Дата: 24.04.15 18:42
Оценка:
Здравствуйте, alex_public, Вы писали:

НС>>Какое?

_>Сформулируй конкретный случай и получишь конкретное оптимальное решение.

Ну вот тебе конкретный случай — Для отображения этого сообщения нужны ID пользователя, его ник, права доступа и метка, если есть. Что твое API будет возвращать?

_>Ты не путай запрос одного пользователя и запрос некого списка. )


Да неважно. У списка то тоже будет тип элемента.

НС>>С Add все понятно. Там и в линке IQueryable скорее всего не будет. Что насчет Select то?

_>Эээ что? ) Вообще то это я спрашивал тебя как будет выглядеть в прикладном коде решение указанной задачи на linq.

Перечитай топик. Вьешся как уж на сковородке, уже которое сообщение избегая ответа на прямой вопрос.

_>Разработчики интерфейса должны определять не "вид запроса", а набор необходимых им данных.


Кто такие "разработчики интерфейса" и чем они отличаются от дизайнеров?

_>>>Ну вот если кто-то говорит, что "поддержка нескольких РСУБД — это редчайшее явление", то это просто автоматический диагноз, что человек вообще не в курсе веб-разработки.

НС>>Ну ну. Много дон веб-разработал то? А то чета гложут меня смутные сомнения.
_>Вообще то для подобного утверждения вообще нет необходимости создавать самому какие-то веб-приложения

А, ну ну.

_>Кстати, если вспомнить статистику из таких анализов, то можно сделать очень забавный вывод, в контексте нашей дискуссии. Как я уже сказал, большинство веб-движков умеют работать с несколькими СУБД.


Опять какие то абстрактные веб-движки. Большинство веб движков написано на РНР, что совсем не означает что РНР как язык это оптимальное техническое решение.
Я вот постоянно вынужден тебя небес спускать. Посмотри на этот сайт — он, как известно, работает на mssql. Причем делает то уже 14 лет. Ну и как, помогла бы ему поддержка других БД?

_>Только вот самое интересное заключается в том, что это за СУБД такая: практически всегда это та самая mysql!


Это как раз не удивительно. mysql настолько убог, что, хоть и с трудом, но можно решения с его использованием перенести на нормальные сервера. А вот когда в коде больше 3.5 тупейших запросов, то тут уже все не так просто.
Re[51]: EntityFramework - тормоз
От: alex_public  
Дата: 24.04.15 19:43
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ну вот тебе конкретный случай — Для отображения этого сообщения нужны ID пользователя, его ник, права доступа и метка, если есть. Что твое API будет возвращать?


Слишком мало информации. Надо ещё знать что там за таблицы у нас и что за выдача информации (один пользователь или много и т.д и т.п.). )

_>>Ты не путай запрос одного пользователя и запрос некого списка. )

НС>Да неважно. У списка то тоже будет тип элемента.

Очень даже важно. При запросе одной строки, ты не почувствуешь разницы в производительности если будешь запрашивать её всю или же набор отдельных полей. А вот при запросе большого количества строк разница уже появляется...

_>>Эээ что? ) Вообще то это я спрашивал тебя как будет выглядеть в прикладном коде решение указанной задачи на linq.

НС>Перечитай топик. Вьешся как уж на сковородке, уже которое сообщение избегая ответа на прямой вопрос.

Я избегаю? Ты бредишь? ) Тут вообще то я тебе последние два сообщения задаю вопрос (и я же привёл пример кода, относительно которого идут вопросы) о том, как будет выглядеть код на linq, аналогичный моему примеру со слоем абстракции БД, а ты не отвечаешь.

_>>Кстати, если вспомнить статистику из таких анализов, то можно сделать очень забавный вывод, в контексте нашей дискуссии. Как я уже сказал, большинство веб-движков умеют работать с несколькими СУБД.

НС>Опять какие то абстрактные веб-движки. Большинство веб движков написано на РНР, что совсем не означает что РНР как язык это оптимальное техническое решение.

Хыхы, ну вот сам и проговорился. ))) Понятно, что ты прекрасно понимаешь что такое веб-движки, вот даже статистику по их языками знаешь. Однако аналогичную статистику по поддерживаемым ими СУБД ты конечно же воспринимать не хочешь. )))

НС>Я вот постоянно вынужден тебя небес спускать. Посмотри на этот сайт — он, как известно, работает на mssql. Причем делает то уже 14 лет. Ну и как, помогла бы ему поддержка других БД?


Потому как этот сайт использует не готовый движок, а некий свой велосипед.

НС>Это как раз не удивительно. mysql настолько убог, что, хоть и с трудом, но можно решения с его использованием перенести на нормальные сервера. А вот когда в коде больше 3.5 тупейших запросов, то тут уже все не так просто.


У тебя что-то не так с логикой. ))) Сейчас имеем в большинстве веб-движков: или поддержку многих СУБД (естественно включая mysql) или только mysql. А если бы была верна твоя логика, то имели бы: или одна какая-то нормальная СУБД (не mysql) или одна какая-то СУБД+mysql (на которую типа легко портировать). Так что твоя замечательная логика расходится с реальностью. )))
Re[40]: EntityFramework - тормоз
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.04.15 20:01
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Очень непрофессиональный первый взгляд. Тем более, что в этой теме уже были ссылки на примеры, демонстрирующие все техники, необходимые для реализации примера выше. Ну если провести аналогию от примеров из библиотеки к данному так сложно, то я могу помочь:

_>
_>Sales::Person p; Sales::Order o;
_>auto y=select(o.person, sum(o.total).as(year_sales), o.year).from(o).where(is_not_null(o.person)).group_by(o.person, o.year).as(sqlpp::alias::y);
_>auto a=select(p.branch, avg(y.year_sales).as(branch_avg), y.year).from(p.join(y).on(p.id==y.person)).where(true).group_by(p.branch, y.year).as(sqlpp::alias::a);
_>auto q=select(p.id).from(p.join(y).on(p.id==y.person).join(a).on(p.branch==a.branch)).where(y.year_sales>a.branch_avg);
_>

_>Это компилируемый код, если что. )))
Вопрос не в том, компилируемый он или нет. Вопрос в том, что помешает скомпилироваться и коду с ошибками. Например,
auto y=select(o.person, sum(o.total).as(year_sales), o.year).from(o).where(is_not_null(o.person)).as(sqlpp::alias::y);
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: EntityFramework - тормоз
От: Evgeny.Panasyuk Россия  
Дата: 24.04.15 20:56
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Вопрос не в том, компилируемый он или нет. Вопрос в том, что помешает скомпилироваться и коду с ошибками.


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

Насколько я понял, в sqlpp11 логика (или по крайней мере её часть) задаётся в конкретном connector'е (PostgreSQL, MySQL, Sqlite3, STL Container). Есть ли там правило на группировку — надо проверять.
Re[52]: EntityFramework - тормоз
От: Ночной Смотрящий Россия  
Дата: 24.04.15 21:47
Оценка:
Здравствуйте, alex_public, Вы писали:

НС>>Ну вот тебе конкретный случай — Для отображения этого сообщения нужны ID пользователя, его ник, права доступа и метка, если есть. Что твое API будет возвращать?

_>Слишком мало информации.



_> Надо ещё знать что там за таблицы у нас и что за выдача информации (один пользователь или много и т.д и т.п.). )


Пусть будет один пользователь, права доступа и ник в одной таблице, метка в другой по джойну.

_>>>Ты не путай запрос одного пользователя и запрос некого списка. )

НС>>Да неважно. У списка то тоже будет тип элемента.
_>Очень даже важно. При запросе одной строки, ты не почувствуешь разницы в производительности

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

_>Я избегаю?


Ты.

_> Ты бредишь?


Нет.

_> ) Тут вообще то я тебе последние два сообщения задаю вопрос


Во во, отвечаешь вопросом на вопрос и стрелки переводишь.

НС>>Я вот постоянно вынужден тебя небес спускать. Посмотри на этот сайт — он, как известно, работает на mssql. Причем делает то уже 14 лет. Ну и как, помогла бы ему поддержка других БД?

_>Потому как этот сайт использует не готовый движок, а некий свой велосипед.

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

_>Сейчас имеем в большинстве веб-движков: или поддержку многих СУБД (естественно включая mysql) или только mysql.


Ты причину попутал. Там поддержка нескольких СУБД как раз потому что это движки. Суррогат программный, понимаешь?

_> А если бы была верна твоя логика, то имели бы: или одна какая-то нормальная СУБД (не mysql) или одна какая-то СУБД+mysql (на которую типа легко портировать).


И такое тоже есть. Посмотри на sharepoint.
Re[42]: EntityFramework - тормоз
От: Ночной Смотрящий Россия  
Дата: 24.04.15 21:48
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


Т.е., по сути, большой кусок компилятора своими руками на шаблонах. Все таки у вас, любителей шаблонного метапрограммирования, на редкость вывернуто понятие добра и зла в программировании.
Re[43]: EntityFramework - тормоз
От: Evgeny.Panasyuk Россия  
Дата: 24.04.15 23:01
Оценка: +1
Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>Т.е., по сути, большой кусок компилятора своими руками

Дерево выражения компилятор строит сам — то есть своего рода цитирование.
А логика EDSL — она и в linq2db вообще-то требуется — или она там какая-то тёплая и ламповая?

НС>на шаблонах.


1. На шаблонах есть pattern-matching, что в данном контексте упрощает задачу.
2. Не только на шаблонах. Есть ещё и constexpr — функции времени компиляции
Автор: Evgeny.Panasyuk
Дата: 24.04.15
.

Да и вообще я говорил не только про C++, но и например про D и Nemerle

НС>Все таки у вас, любителей шаблонного метапрограммирования, на редкость вывернуто понятие добра и зла в программировании.


Про "мозаичное сознание" ты уже рассказал, давай теперь про добро и зло. И побольше овер-обобщений, а то ведь без демагогии не интересно, правда?
Re[44]: EntityFramework - тормоз
От: Ночной Смотрящий Россия  
Дата: 24.04.15 23:02
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Дерево выражения компилятор строит сам — то есть своего рода цитирование.


Это мелочь. Проверка типов намного веселее.

EP>А логика EDSL — она и в linq2db вообще-то требуется — или она там какая-то тёплая и ламповая?


Типы проверяет не linq2db, а компилятор шарпа.
Re[45]: EntityFramework - тормоз
От: Evgeny.Panasyuk Россия  
Дата: 24.04.15 23:27
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

EP>>А логика EDSL — она и в linq2db вообще-то требуется — или она там какая-то тёплая и ламповая?

НС>Типы проверяет не linq2db, а компилятор шарпа.

Ты о чём конкретно? Типы в C++ тоже проверяет компилятор
Автор: Evgeny.Panasyuk
Дата: 22.04.15
.
Re[46]: EntityFramework - тормоз
От: Ночной Смотрящий Россия  
Дата: 25.04.15 07:38
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Ты о чём конкретно? Типы в C++ тоже проверяет компилятор
Автор: Evgeny.Panasyuk
Дата: 22.04.15
.


S>Вопрос не в том, компилируемый он или нет. Вопрос в том, что помешает скомпилироваться и коду с ошибками.
Помешает логика закодированная в коде который обходит дерево выражения.


Re[41]: EntityFramework - тормоз
От: alex_public  
Дата: 25.04.15 11:24
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Вопрос не в том, компилируемый он или нет. Вопрос в том, что помешает скомпилироваться и коду с ошибками. Например,

S>
S>auto y=select(o.person, sum(o.total).as(year_sales), o.year).from(o).where(is_not_null(o.person)).as(sqlpp::alias::y);

Хы, ну вот конкретно этой проверки в библиотечке действительно нет. Это ты удачно попал (или лазил по исходникам?). Хотя добавить её элементарно, т.к. агрегирующие функции и так уже выделены в отдельный класс для других проверок (например для запрета вызова друг друга). Так что автору библиотечки видимо просто не пришло в голову делать такое (проверять не правильность существующего кода, а отсутствие кода). Но ты же помнится перед этим упирал на совершенно другое: "в процессе сборки дерева выводятся типы промежуточных результатов и всё проверяется". Не хочешь попробовать подобные ошибки сделать в данном коде?

P.S. Да, кстати, а можно за одно привести linq код для данного примера? ) Я как бы не сомневаюсь, что это легко делается, просто хочется сравнить объём кода с sqlpp вариантом. По идее же оно должно быть проще и компактнее чем на C++, т.к. sql конструкции по сути введены в язык.
Re[53]: EntityFramework - тормоз
От: alex_public  
Дата: 25.04.15 11:58
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Пусть будет один пользователь, права доступа и ник в одной таблице, метка в другой по джойну.


А что за метка вообще и в какой она таблице? )
Если бы не метка, то ответ уже был бы и ты думаю понимаешь какой. )))

_>>Очень даже важно. При запросе одной строки, ты не почувствуешь разницы в производительности

НС>Почувствуешь, если выборка не по кластерному индексу. Но пусть будет список, а то намеки на index includes от нескольких собеседников ты с завидной упорностью игнорируешь.

Ну так а зачем эти намёки, если речь была про User GetUser(int id)? )

_>> ) Тут вообще то я тебе последние два сообщения задаю вопрос

НС>Во во, отвечаешь вопросом на вопрос и стрелки переводишь.

Вот в этом http://rsdn.ru/forum/flame.comp/6024953
Автор: alex_public
Дата: 22.04.15
сообщение в ответ на твоё утверждение, что "IQueryable, если что, он на самом деле IQueryable<T> в котором Т вполне себе родной." я предложил тебе продемонстрировать взаимодействие с этим "родным" интерфейсом на конкретном примере. А ты в ответ не привёл ни строчки кода и ещё мне какие-то претензии предъявляешь. )

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


Угу, только в сайтах на "движках" почему-то вся функциональность всегда работает (причём там есть к примеру форумы входящие в топ alexa, т.е. понятно с какими дикими нагрузками), а на rsdn имеем баг на баге (уже в этой темке 2 отмечено, причём один из них имеет многолетнюю историю, но никто его исправить не может). И это с учётом того, что большинство движков написано на убогом php, а rsdn на вроде как правильном языке. Позор какой-то получается...

_>>Сейчас имеем в большинстве веб-движков: или поддержку многих СУБД (естественно включая mysql) или только mysql.

НС>Ты причину попутал. Там поддержка нескольких СУБД как раз потому что это движки. Суррогат программный, понимаешь?

Естественно потому что движки, т.е. софт, который будет работать много где. Софту предназначенному для одиночной установки само собой не нужна поддержка нескольких БД. Только вот коробочный софт всегда был намного качественнее всякого внутреннего софта. Вроде как ты сам в соседней темке ругал Шеридана за то, что он писал свой велосипед, вместо использования готового решения. А что же тут у тебя мнение резко поменялось? )))
Re[54]: EntityFramework - тормоз
От: Ночной Смотрящий Россия  
Дата: 25.04.15 17:18
Оценка:
Здравствуйте, alex_public, Вы писали:

НС>>Пусть будет один пользователь, права доступа и ник в одной таблице, метка в другой по джойну.

_>А что за метка вообще и в какой она таблице? )

У юзеров иногда метки рядом с ником бывают — expert, admin и т.д.

_>Если бы не метка, то ответ уже был бы и ты думаю понимаешь какой. )))


Нет, не понимаю.

НС>>Почувствуешь, если выборка не по кластерному индексу. Но пусть будет список, а то намеки на index includes от нескольких собеседников ты с завидной упорностью игнорируешь.

_>Ну так а зачем эти намёки, если речь была про User GetUser(int id)? )

Нет, речь была про общий случай, который ты упорно пытаешься сузить.

_>>> ) Тут вообще то я тебе последние два сообщения задаю вопрос

НС>>Во во, отвечаешь вопросом на вопрос и стрелки переводишь.
_>Вот в этом http://rsdn.ru/forum/flame.comp/6024953
Автор: alex_public
Дата: 22.04.15
сообщение в ответ на твоё утверждение, что "IQueryable, если что, он на самом деле IQueryable<T> в котором Т вполне себе родной." я предложил тебе продемонстрировать взаимодействие с этим "родным" интерфейсом на конкретном примере.


Вопрос непонятен.

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

_>Угу, только в сайтах на "движках" почему-то вся функциональность всегда работает

Агащаз.

_> (причём там есть к примеру форумы входящие в топ alexa, т.е. понятно с какими дикими нагрузками)


А ты уверен что там нетроганный руками движок на этих диких нагрузках?

_>>>Сейчас имеем в большинстве веб-движков: или поддержку многих СУБД (естественно включая mysql) или только mysql.

НС>>Ты причину попутал. Там поддержка нескольких СУБД как раз потому что это движки. Суррогат программный, понимаешь?
_>Естественно потому что движки

Ну вот и выхода у них другого нет, приходится лишний слой городить.

_>Вроде как ты сам в соседней темке ругал Шеридана за то, что он писал свой велосипед, вместо использования готового решения.


Вот уж передернул так передернул.

_> А что же тут у тебя мнение резко поменялось? )))


Нет, у меня резко поменялось желание с тобой продолжать разговор.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.