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

IT>linq2db поддерживает DDL операции, в том числе создание (временных) таблиц.
Если не секрет, как?

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

IT>>linq2db поддерживает DDL операции, в том числе создание (временных) таблиц.
V>Если не секрет, как?

Своим собственным расширением. Создаётся таблица вызовом метода CreateTable, возвращается IQueriable объект, который дальше можно использовать в Linq как обычно. Также в наличии DML операции, соответственно новую таблицу можно заполнить данными на серверной стороне и использовать её в более сложных запросах.

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

IT>Здравствуйте, 80LevelElf, Вы писали:

LE>>Так же я бы на вашем месте присмотрелся бы к https://github.com/igor-tkachev/bltoolkit .
LE>>Сам не работал(только собираюсь), но судя по всему очень крутая вещь. Ну и как минимум комьюнити не далеко(в соседней ветке форума ).

IT>Лучше сразу использовать linq2db.
Игорь тысячу раз говорили что что бы его начать использовать в серьёзных проектах должен быть соответствующий уровень поддержки.
Если не платный продукт то хотя бы вариант платной поддержки.
Я вот даже если хочу не смогу его пропихнуть черехз наших legals-ов и прочих товарисчей.

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

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

IT>>>linq2db поддерживает DDL операции, в том числе создание (временных) таблиц.
V>>Если не секрет, как?

IT>Своим собственным расширением. Создаётся таблица вызовом метода CreateTable, возвращается IQueriable объект, который дальше можно использовать в Linq как обычно. Также в наличии DML операции, соответственно новую таблицу можно заполнить данными на серверной стороне и использовать её в более сложных запросах.


Главный вопрос не как, а зачем

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

Tom>Главный вопрос не как, а зачем

При использовании сохранённых процедур это весьма распространённая практика. Поэтому, для облегчения переноса кода на linq такое дело может облегчить задачу. Ещё полезно для очень тяжёлых запросов с пейджингом, требующих кроме самих данных ещё и count. Тогда закатываем данные во временную таблицу, получаем count, а затем возаращаем нужную страницу. Извратство, знаю, но бывает полезно.

Сам я стараюсь обходиться без временных таблиц.

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

Tom>Игорь тысячу раз говорили что что бы его начать использовать в серьёзных проектах должен быть соответствующий уровень поддержки.
Tom>Если не платный продукт то хотя бы вариант платной поддержки.

Гусары денег с юзеров не берут.

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

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

G>>Это женская логика.
IB>Сначала ты везде кричал, что они все поправили и SQL генерится самый лучший на свете. Я тебе показал, что это не так, но ты продолжаешь утверждать, что это фигня. Я тебе объяснил, что это косяк в архитектуре, а не просто ошибка, разработчики подтвердили тебе, что это by design, но ты все равно голову куда-то засовываешь. Вот это — женская логика.
Откровенное вранье.
1) Я не утверждал что в EF "SQL генерится самый лучший на свете", я говорил что в совокупности покачто нет ничего лучше.
2) Ты показал ровно один баг, который легко обходится. На "косяк в архитектуре" один баг не тянет.
3) "разработчики подтвердили тебе, что это by design" — вранье

G>> Единичный пример не показывает ничего "в принципе". Также как единичный баг не говорит о качестве приложения "в принципе".
IB>Еще один пример женской логики и неумения видеть проблему в целом.
Суждение "в целом" по одному косяку — пример женской логики.

IB>Если единичный баг — системный и его нельзя поправить на протяжении нескольких лет потому что by design, то это таки говорит о качестве и архитектуре приложения "в принципе".
С чего ты взял что он системный? Это лишь твои домыслы.


G>> Тебе уже более одного раза мягко намекали, что твой подход крайне непрофессионален.
IB>Душа моя, не тебе рассказывать мне про мою профессиональность. Мне глубоко не интересно, что думает о моей профессиональности человек, который не может вести диалог без перехода на личности и уж совсем не интересно собирать для него доказательную базу, если он очевидных примеров под носом не видит.
Какие "очевидные примеры"? Ты показал один. В любом ORM найдется как минимум один баг.

G>> EF последовательно развивался с 2009 года, было 4 мажорных релиза и около 10 минорных.
IB>Не с 2009, а с 2003 и не уверен, что эпитет "последовательно" здесь применим.
Да хоть с рождения христа, какая разница? Реально EF стал юзабелен с версии 5, то есть два года назад. Но видимо ты его видел крайний раз в том самом 2003 году.

G>> Никто не думал о переписывании, пока не появилось два кейса примерно в одно и тоже время — KRuntime и SQLite на Windows 8. На обоих EF не работает, просто исторически так сложилось, никогда не было целью обеспечить работу EF на мини-фреймворках. Поэтому собрались переписать.
IB>И все таки — научись читать пресс-релизы. В жизни пригодится. Как минимум может помочь вовремя сбегать с мертвых технологий.
IB>Снова цитирую реальные причины отказа от EF, а то ты похоже уже забыл или не дочитал:
IB>we’ve had to take a realistic look at our current code base.
IB>the code base is monolithic in nature which makes it difficult to implement new features and increasingly harder to change things without breaking existing functionality.
IB>there are many seldom used features and capabilities in the code base that hamper performance and complicate development, but are not feasible to remove due to the monolithic nature of the implementation. We also have a number of unintuitive behaviors that are engrained into the framework and hard to change or remove for the same reasons.

IB>А, и мое любимое, к вопросу об изначально неправильной идеологии, которая лежит в основе EF и до сих пор торчит изо всех мест:
IB>When Entity Framework began life, it’s charter was more to do with the Entity Data Model vision rather than being a best-of-breed O/RM.

Я слишком хорошо знаю как работает маркетинг МС, чтобы не верить ни одному пресс-релизу. Поэтому я читаю код вместо маркетингового буллшита.

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

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

IT>>>linq2db поддерживает DDL операции, в том числе создание (временных) таблиц.
V>>Если не секрет, как?

IT>Своим собственным расширением. Создаётся таблица вызовом метода CreateTable, возвращается IQueriable объект, который дальше можно использовать в Linq как обычно. Также в наличии DML операции, соответственно новую таблицу можно заполнить данными на серверной стороне и использовать её в более сложных запросах.

Я был бы рад увидеть примеры применения всех возможностей linq2db. Кривая изучения с помощью исходников слишком кривая для реального применения.

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

G>Я был бы рад увидеть примеры применения всех возможностей linq2db. Кривая изучения с помощью исходников слишком кривая для реального применения.

С чего начать?

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

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

G>>Я был бы рад увидеть примеры применения всех возможностей linq2db. Кривая изучения с помощью исходников слишком кривая для реального применения.

IT>С чего начать?

1) пошаговый гайд подключения к проекту с разными субд
2) описание мэппинга, ключи, коллекции, nullable
3) построение сложных linq запросов, декомпозиция, функции, fts, как сделать fulljoin итп
4) пример приложения, взять готовый mvc music store и переписать на linq2db
5) пошаговый гайд по миграции с рукопашных запросов на linq2db
6) описание фишек для временных таблиц и чего там еще есть

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

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

Tom>>Игорь тысячу раз говорили что что бы его начать использовать в серьёзных проектах должен быть соответствующий уровень поддержки.
Tom>>Если не платный продукт то хотя бы вариант платной поддержки.

IT>Гусары денег с юзеров не берут.

Вам дело советуют. Это же хороший продукт! Так поднимите с него денег. Тестерам дадите, или еще кому. Визуальный редактор, code-first и прочие удобства будут не лишними, но писать это — муторно. Пускай это люди за деньги пишут.

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

AK>Здравствуйте, Аноним, Вы писали:

AK>>>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?
А>>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить", это всегда эффективнее делать на уровне СУБД.

AK>Насколько я помню, EntityFramework не гоняет данные туда-сюда без нужды. Оно генерирует SQL-запрос и все данные обрабатываются на стороне сервера, т.е. из C# кода вы можете делать с данными почти тоже самое, что и через прямой SQL.
AK>Пересылать данные на сторону сервера приложений оно начинает только тогда, когда Вы эти данные вытаскиваете из IQueryable и начинаете обрабатывать построчно C# кодом. Но это уже вполне логично, это уже выходит за рамки SQL-кода вообще и хранимых процедур в частности.

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

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

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

IT>Здравствуйте, Аноним, Вы писали:

А>>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить",

IT>Это неверное утверждение.

Обоснуйте.
На практике нет возможности все действо в 1м запросе сделать. Иногда требуется выполнить запрос1 и его данные как правило не нужны, требуется его постобработка и только тогда уже нужные данные получаются.
Если не верите почитайте зачем временные таблицы нужны например.

IB>И все таки — научись читать пресс-релизы. В жизни пригодится. Как минимум может помочь вовремя сбегать с мертвых технологий.
IB>Снова цитирую реальные причины отказа от EF, а то ты похоже уже забыл или не дочитал:
IB>we’ve had to take a realistic look at our current code base.
IB>the code base is monolithic in nature which makes it difficult to implement new features and increasingly harder to change things without breaking existing functionality.
IB>there are many seldom used features and capabilities in the code base that hamper performance and complicate development, but are not feasible to remove due to the monolithic nature of the implementation. We also have a number of unintuitive behaviors that are engrained into the framework and hard to change or remove for the same reasons.
А вас не пугает в EF7 вот это:

EF7 Enables New Data Stores

While parts of Entity Framework are clearly tied to relational data stores, much of the functionality that EF provides is applicable to many non-relational data stores too. Examples of such functionality include change tracking, LINQ, and unit of work. In EF7 we will be enabling providers that target non-relational data stores, such as Azure Table Storage.

We are explicitly not trying to build an abstraction layer that hides the type of data store you are targeting. The common patterns/components that apply to most data stores will be handled by the core framework. Things that are specific to particular types of data stores will be available as extensions that are included as part of the provider. For example, the concept of a model builder that allows you to configure your model will be part of the core framework. However, the ability to configure things such as cascade delete on a foreign key constraint will be included as extensions in the relational database provider.

Все эти common patterns и extensions меня настораживают. Дьявол то в деталях, и то, что на поверхности выгляди как common, в деталях может оказаться совсем не common, или common часть совсем тривиальной.

Здравствуйте, Аноним, Вы писали:

А>На практике нет возможности все действо в 1м запросе сделать. Иногда требуется выполнить запрос1 и его данные как правило не нужны, требуется его постобработка и только тогда уже нужные данные получаются.

Всё так.

А>Если не верите почитайте зачем временные таблицы нужны например.

С временными таблицами можно легко работать без сохранённых процедур. В том числе на linq.

IT>С временными таблицами можно легко работать без сохранённых процедур. В том числе на linq.

При работе с пулом, .net дает гарантии что 2 запроса выполнятся в одной сессии ?

Здравствуйте, Аноним, Вы писали:

IT>>С временными таблицами можно легко работать без сохранённых процедур. В том числе на linq.
А>При работе с пулом, .net дает гарантии что 2 запроса выполнятся в одной сессии ?

При чём тут пул? Открывается соединение, которое берётся из пула, затем на нём выполняются команды. Существует проблема с некоторыми драйверами типа DB2, которые после каждой команды выполняют комит и не дают возможности это действие отменить, в результате временные таблицы, живущие до комита недоступны следующей команде. Но это всё мелочи и с этим можно бороться. А так всё работает шо железная железяка.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Artem Korneev, Вы писали:

AK>>Здравствуйте, Аноним, Вы писали:

AK>>>>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?
А>>>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить", это всегда эффективнее делать на уровне СУБД.

AK>>Насколько я помню, EntityFramework не гоняет данные туда-сюда без нужды. Оно генерирует SQL-запрос и все данные обрабатываются на стороне сервера, т.е. из C# кода вы можете делать с данными почти тоже самое, что и через прямой SQL.
AK>>Пересылать данные на сторону сервера приложений оно начинает только тогда, когда Вы эти данные вытаскиваете из IQueryable и начинаете обрабатывать построчно C# кодом. Но это уже вполне логично, это уже выходит за рамки SQL-кода вообще и хранимых процедур в частности.

А>Нет волшебных запросов, т.е. на практике при обработке данных бывает сложно всю обработку в один запрос уместить и нужно сначала пройтись по результататм одного запроса, на базе этих данных или по условиям сформировать дополнительные запросы.
Подзапросы отменили? Вообще с использованием CTE запрос select является полным по тьюрингу, то есть абсолютно любую выборку можно сделать ровно одним селектом.
Так как в insert\update\delete можно использовать результаты select запроса, то в принципе можно сделать все.

Конечно упирается все в выразительную силу SQL и способность приложения генерировать такие запросы. Но на практике в среднем приложении довольно сложно придумать запрос, который обязательно надо сделать внутри процедуры, а не просто батчем.

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

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

G>>Я был бы рад увидеть примеры применения всех возможностей linq2db. Кривая изучения с помощью исходников слишком кривая для реального применения.

IT>С чего начать?

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

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

IT>>Лучше сразу использовать linq2db.
Tom>Игорь тысячу раз говорили что что бы его начать использовать в серьёзных проектах должен быть соответствующий уровень поддержки.

И какой у EF6+ уровень поддержки? Проект на codeplex как открыли так и закрыть можно.