var value = "some value";
//1
db.MyObject.Set(_ => _.Field, value).Update();
//2
db.MyObject.Set(_ => _.Field, () => value).Update();
выход у них такой:
--1UPDATE MyObject SET Field = 'some value'
--2UPDATE MyObject SET Field = @parameter
зачем инлайнить параметр как константу?
да и кэширование в таком случае отрубается, точнее, работает, только в случае, если значение константы совпадает.
Здравствуйте, ili, Вы писали:
ili>зачем инлайнить параметр как константу?
Так компилятор строит Expression.
ili>да и кэширование в таком случае отрубается, точнее, работает, только в случае, если значение константы совпадает.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Так компилятор строит Expression.
может я сейчас глупость скажу, но, это вроде можно обойти:
на константу отрабатывает
UpdateBuilder.ParseSet(
ExpressionBuilder builder,
BuildInfo buildInfo,
LambdaExpression extract,
Expression update,
IBuildContext select)
из него зовется:
ExpressionBuilder.SqlBulder.ConvertToSql(IBuildContext context, Expression expression)
{
// если пропустить этот шаг в дебагере, то выражение будет построено с параметром, а не с инлайномif (CanBeConstant(expression))
return BuildConstant(expression);
if (CanBeCompiled(expression))
return BuildParameter(expression).SqlParameter;
Здравствуйте, ili, Вы писали:
IT>>А если я хочу именно константу? ili>а зачем?
На практике планы запросов с параметром от с константой иногда фатально отличаются.
Здравствуйте, ili, Вы писали:
ili>эв оно как... ну тада ладно.. ili>ну вот тогда у мяня такой вопрос возникает, DateTime инлайниться не будет?
Этого уже не знаю. Сейчас кривая меня опять от BLT подальше отвела.