Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Как обычно все немного сложнее. Процедуры компилируются в момент первого вызова, причем с учетом параметров, которые передали в процедуру. План, оптимальный для этих параметров, может быть крайне неоптимальным для других. При вызове sqlcommand с параметрами запрос попадает в sp_executesql, где принудительно параметизуется. Таким образом для linq запросов создается план который работает одинаково (хорошо или плохо — зависит от кучи факторов), а для хранимок может быть закеширован план, который работает хорошо на одном значении параметра и ужасно на другом.
S>Так, я всё-таки торможу
S>Для хранимок: S> план строится по первому запуску, строится по переданным аргументам, кэшируется до выпадения из кэша.
S>Для параметризованного sql (sp_executesql): S> план строится по первому запуску, строится по переданным аргументам, кэшируется до выпадения из кэша.
S> * про авто-параметризацию пока забудем, считаем что в executesql пришёл запрос с явно прописанными параметрами.
S>В чём разница?
Опять все немного сложнее. если внутри процедуры обычный select, то разницы нет. Но часто в процедуре много действий, которые делают план очень нестабильным (в разных случаях оптимальный путь исполнения будет сильно отличаться). В sp_executesql всегда прилетает один запрос (при использовании linq), для которого почти всегда можно построить стабильный план (особенно за счет добавления покрывающих индексов), что чаще всего и происходит.
Здравствуйте, gandjustas, Вы писали:
G>Опять все немного сложнее. если внутри процедуры обычный select, то разницы нет. Но часто в процедуре много действий, которые делают план очень нестабильным (в разных случаях оптимальный путь исполнения будет сильно отличаться).
Угу, с таким объяснением согласен. Спасибо!
Здравствуйте, gandjustas, Вы писали:
G>Это ты уверяешь что проблемы есть, но примеры не приводишь. Воистину — вера страшная штука.
Главное, что моя вера совпадает с верой разработчиков, так что мое кун-фу круче =)
G>Судя по тому что ты пишешь — нет.
Ты видимо что-то не то читаешь..
G>А атрибуты не добавляют? Такие же классы, также через них маппинг делется.
Не прикидывайся. Если не понятно, можешь еще раз прочитать пресс-релиз о причинах закрытия EF6 или почитать текст исключения при попытках составить не тривиальный linq запрос... Очень показательно, кстати, выдает что-то типа "внутренняя модель так не может". Это при том что code-first и прямой маппинг, и никакой такой модели не видно — нет никакой ложки.
G>Ты как-то хитро отбросил часть моей фразы про исправление конкретных проблем. Твои идеи по поводу "идеологии" не интересуют вообще, я про конкретику уже хрен знает какой раз спрашиваю, а ответа все нет, ты все про идеологию.
Если ты не понимаешь, что корни всех конкретных проблем лежат именно в идеологии, то я тут бессилен. При кривой изначальной идее можно заткнуть конкретную проблему.. Одну, может две. Но что-то отвалится в другом месте. А при попытке добавить новый функционал — совсем все развалится.
Что, собственно, с EF и произошло — очень наглядный пример, что кривую идеологию никакая реализация не исправит.
G>Не похоронили, а наконец собрались переписать.
Что в лоб, что полбу =)
G>Текущая версия отлично работает для тех сценариев, для которых она заточена.
Она заточена под несуществующие сценарии и совсем не работает в реальной жизни — there are many seldom used features and capabilities in the code base that hamper performance and complicate development. Или вот — We also have a number of unintuitive behaviors that are engrained into the framework.
G>С точки зрения API в новой версии мало что изменится, будет вполне нормальный upgrade path.
Свежо придание )
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>Это ты уверяешь что проблемы есть, но примеры не приводишь. Воистину — вера страшная штука. IB>Главное, что моя вера совпадает с верой разработчиков, так что мое кун-фу круче =)
Тем не менее твоя вера расходится с фактами. Как бы тебе не верилось обратное.
G>>Судя по тому что ты пишешь — нет. IB>Ты видимо что-то не то читаешь..
Ты же ни одного факта не привел, а религиозный бред уже фильтрую не задумываясь.
G>>А атрибуты не добавляют? Такие же классы, также через них маппинг делется. IB>Не прикидывайся. Если не понятно, можешь еще раз прочитать пресс-релиз о причинах закрытия EF6 или почитать текст исключения при попытках составить не тривиальный linq запрос... Очень показательно, кстати, выдает что-то типа "внутренняя модель так не может". Это при том что code-first и прямой маппинг, и никакой такой модели не видно — нет никакой ложки.
Так приведи запрос который не может осилить ef в принципе, но легко осиливается другим linq провайдером.
Или ты оцениваешь технологии исключительно о пресс-релизам? Это верх профессионализма сейчас?
G>>Ты как-то хитро отбросил часть моей фразы про исправление конкретных проблем. Твои идеи по поводу "идеологии" не интересуют вообще, я про конкретику уже хрен знает какой раз спрашиваю, а ответа все нет, ты все про идеологию. IB>Если ты не понимаешь, что корни всех конкретных проблем лежат именно в идеологии, то я тут бессилен.
Ну естественно бессилен, ибо ты веришь, а я проверяю. Попробуй тоже проверить, сразу развенчаешь свои заблуждения.
IB>При кривой изначальной идее можно заткнуть конкретную проблему.. Одну, может две. Но что-то отвалится в другом месте. А при попытке добавить новый функционал — совсем все развалится. IB>Что, собственно, с EF и произошло — очень наглядный пример, что кривую идеологию никакая реализация не исправит.
Опять идеологическая чушь. Почему-то при кривой идеологии чуваки смогли прикрутить к ef кучу фич, тип асинхронности, code-first, миграций, повысили быстродействие на порядки, создали community с кучей расширений и провайдеров. Дай бог каждому такие «кривые» идеи придумывать.
G>>Не похоронили, а наконец собрались переписать. IB>Что в лоб, что полбу =)
То есть roslyn == похоронили c#, asp.net vnext == похоронили asp.net, любой мажорный релиз продукта == похоронили продукт?
Отличная логика
G>>Текущая версия отлично работает для тех сценариев, для которых она заточена. IB>Она заточена под несуществующие сценарии и совсем не работает в реальной жизни — there are many seldom used features and capabilities in the code base that hamper performance and complicate development. Или вот — We also have a number of unintuitive behaviors that are engrained into the framework.
Я уже понял что ты технологии по пресс-релизам оцениваешь. Можешь не повторять.
G>>С точки зрения API в новой версии мало что изменится, будет вполне нормальный upgrade path. IB>Свежо придание )
Я бы мог тебе рассказать как прекрасно database-first из 4.1 мигрировался на code-first в 6, но чувствую вера твоя все равно сильнее.
G>Ты же говоришь о решении, а не о проблеме, думаешь за 7 лет ничего не изменилось?
Поменялось, у меня за окном деревья подросли. Но, к сожалению, на механизм декомпозиции эекспрешенов это не повлияло.
Здравствуйте, IB, Вы писали:
IB>Она заточена под несуществующие сценарии и совсем не работает в реальной жизни — there are many seldom used features and capabilities in the code base that hamper performance and complicate development. Или вот — We also have a number of unintuitive behaviors that are engrained into the framework.
Что же они так? Спросили бы меня как надо было делать EF с самого начала. Я бы им ещё лет 5 назад рассказал. Стоило выпускать 6 релизов, чтобы понять, что 7-й нужно переписывать с нуля.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, IB, Вы писали:
IB>>Она заточена под несуществующие сценарии и совсем не работает в реальной жизни — there are many seldom used features and capabilities in the code base that hamper performance and complicate development. Или вот — We also have a number of unintuitive behaviors that are engrained into the framework.
IT>Что же они так? Спросили бы меня как надо было делать EF с самого начала. Я бы им ещё лет 5 назад рассказал. Стоило выпускать 6 релизов, чтобы понять, что 7-й нужно переписывать с нуля.
В .NET дофига компонент, которые лет 5 назад стоило переписать с нуля, но менеджмент видимо не позволял.
С появлением Roslyn и K Runtime перепишут под шумок кучу всего.
Здравствуйте, gandjustas, Вы писали:
IT>>Что же они так? Спросили бы меня как надо было делать EF с самого начала. Я бы им ещё лет 5 назад рассказал. Стоило выпускать 6 релизов, чтобы понять, что 7-й нужно переписывать с нуля.
G>В .NET дофига компонент, которые лет 5 назад стоило переписать с нуля, но менеджмент видимо не позволял.
EF — это всё же отдельно от всего лежащий кусок кала. Ваня правильнос сказал, что практикующим девелоперам ещё лет 10 назад стало понятно каким должно быть средство работы с БД. Но команда EF шла на пролом своим путём.
G>С появлением Roslyn и K Runtime перепишут под шумок кучу всего.
Новый компилятор позволяет переписать устаревший код и сделать его лучше. Но новый компилятор не поможет сделать лучше новую архитектуру. После прочтения их пресс-релиза у меня уже возникают какие-то смутные сомнения. Особенно по поводу "EF7 is Lightweight and Extensible". Один из самых "Extensible" продуктов MS — WCF, хрень, с которой без гугля работать невозможно в принципе. Куда заведут ребят из команды EF новые возможности Рослина не знает никто.
Если нам не помогут, то мы тоже никого не пощадим.
НС>Решается несложным хелпером:
Т.е. всю красоту синтаксиса linq теряем и видим старый неуклюжий Query Object паттерн. Query Object-ов написано куча и на C# и на Java, и все они говно.
НС>Но можно и немножко похитрее, в более общем виде. linq2db.
Т.е. из коробки от Microsoft такого нет. О чем я и говорил, не дизайнился linq для динамических запросов.
Убого это всё выглядит MyMethod, MyMehodExpr, да еще атрибутом надо пометить, фу, простейший Extract Method такой громоздкое убожество вызывает. И это для простоты сопровождения говорите, ну ну. И это вы называли "развитые" средства декомпозиции?
Если сделаю MyMehod и ничего больше писать не буду, то упадет это всё отнюдь не при компиляции, а как раз в рантайме. За что боролись на то и напоролись.
Короче, слишком дорого обходится статическая проверка запросов. Хочется того же, но подешевле.
НС>Давай на конкретных примерах. Перепиши с идентичным поведением и полным сохранением контроля компилятора этот примитивный код без ORM:
А что такое ORM? Вот этот код без ORM:
private static void Example1(DateTime? date)
{
using (var connection = new SqlConnection(ConnectionString))
{
connection.Open();
using (var command = connection.CreateCommand())
{
var builder = new StringBuilder(@"
SELECT Id, CreationDate
FROM Post
WHERE 1 = 1");
if (date.HasValue)
{
builder.Append(@"
AND CreationDate >= @Date");
command.Parameters.AddWithValue("@Date", date);
}
command.CommandText = builder.ToString();
using (var reader = command.ExecuteReader())
{
var idOrdinal = reader.GetOrdinal("Id");
var creationDateOrdinal = reader.GetOrdinal("CreationDate");
while (reader.Read())
{
var id = reader.GetInt32(idOrdinal);
var creationDate = reader.GetDateTime(creationDateOrdinal);
}
}
}
}
}
Теперь пары Пары [id, Int32] и [CreationDate, DateTime] представляем в виде интерфейса:
public interface IPostInfo
{
int Id { get; }
DateTime CreationDate { get; }
}
Тогда, используя runtime кодогенерацию (Emit), код можно переписать следующим образом.
private static void Example1(DateTime? date)
{
using (var connection = new SqlConnection(ConnectionString))
{
connection.Open();
using (var command = connection.CreateCommand())
{
var builder = new StringBuilder(@"
SELECT Id, CreationDate
FROM Post
WHERE 1 = 1");
if (date.HasValue)
{
builder.Append(@"
AND CreationDate >= @Date");
command.Parameters.AddWithValue("@Date", date);
}
command.CommandText = builder.ToString();
using (var reader = command.ExecuteReader())
{
var ordinals = reader.GetOrdinals<IPostInfo>();
while (reader.Read())
{
IPostInfo postInfo = ordinals.Materialize(reader);
}
}
}
}
}
AP>>Т.е. всю красоту синтаксиса linq теряем НС>Нет. Контроль компилятора остается ровно тот же. AP>> и видим старый неуклюжий Query Object паттерн. НС>Тебе показалось.
Query Object тоже дает проверку во время компиляции. Из последнего http://www.jooq.org/
НС>>>Но можно и немножко похитрее, в более общем виде. linq2db. AP>>Т.е. из коробки от Microsoft такого нет НС>И что?
А то, что linq не разрабатывался для динамических запросов к БД, а вы это преподносите как главную фичу.
AP>>Убого это всё выглядит MyMethod, MyMehodExpr НС>Если сравнивать со склейкой строк ...
Если строки автоматически проверяются, то строки проще читать, сопровождать и т.д.
НС>Смысл твоих вопросов и их связь с моим постом непонятна.
У тебя написано "без ORM". Вот я и хочу выяснить смысл этого слова у тебя. Если метод "ordinals.Materialize(reader)" еще не является ORM-ом, то на твой вопрос можно ответить и переписать твой код без ORM.
Здравствуйте, Alexander Polyakov, Вы писали:
НС>>Смысл твоих вопросов и их связь с моим постом непонятна. AP>У тебя написано "без ORM". Вот я и хочу выяснить смысл этого слова у тебя.
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
