Здравствуйте, Ziaw, Вы писали:
Z>Без БД никак Я же написал, что метод сравнения експрешенов в тулките интернал. Поэтому проявить баг можно только в боевом режиме.
Собственно вот чистый тест воспроизводящий проблему:
using System;
using System.Console;
using Nemerle.Extensions;
using System.Linq.Expressions;
class Data
{
public Id : Guid { get; set; }
}
module Program
{
Main() : void
{
def toExpr(e : Expression[Func[Data, bool]]) { e }
mutable id1 = Guid.NewGuid();
mutable id2 = Guid.NewGuid();
def e1 = toExpr(d => d.Id == id1);
def e2 = toExpr(d => d.Id == id2);
def f1 = e1.Compile();
def f2 = e2.Compile();
def d = Data();
d.Id = id1;
WriteLine(f1(d));
WriteLine(f2(d));
id2 = id1;
WriteLine(f1(d));
WriteLine(f2(d));
}
}
Теперь вместо Expression.Constant() для локальных переменных создается Expression.Field(замыкание, поле_из_замыкания), так что проблем быть не должно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Guid в CLR в принципе нельзя объявить константой.
Казалось бы причем тут коснтсанты CLR? Речь идет о деревьях выражений в которых Constant — это не более чем захват значений.
IT>Если какая-либо программа учитывает этот факт, то кто будет виноват — компилятор или эта программа?
Пока что единственной программой которая учитывает "факт" — это твой провайдер. Остальные работают корректно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Guid в CLR в принципе нельзя объявить константой. VD>Казалось бы причем тут коснтсанты CLR? Речь идет о деревьях выражений в которых Constant — это не более чем захват значений.
Именно формированием дерева выражения в ручную я этот баг и воспроизводил. А при желании ручным формированием деревьев выражений можно завалить любой провайдер. И сказать при это, что это не более чем дерево выражений, при чём тут компилятор.
IT>>Если какая-либо программа учитывает этот факт, то кто будет виноват — компилятор или эта программа? VD>Пока что единственной программой которая учитывает "факт" — это твой провайдер. Остальные работают корректно.
А сколько ты их проверял?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Именно формированием дерева выражения в ручную я этот баг и воспроизводил. А при желании ручным формированием деревьев выражений можно завалить любой провайдер. И сказать при это, что это не более чем дерево выражений, при чём тут компилятор.
Ну, то есть то что все остальные провайдеры ведут себя нормально — это у них баг.
Кроме того нормальным по видимому является и то, что твой провадер вместо того чтобы сообщить пользователю о том, что переданное ему дерево выражений, с его точки зрения не корректно, просто выдает не верный результат.
"Хорошая" позиция.
IT>>>Если какая-либо программа учитывает этот факт, то кто будет виноват — компилятор или эта программа? VD>>Пока что единственной программой которая учитывает "факт" — это твой провайдер. Остальные работают корректно.
IT>А сколько ты их проверял?
Столько сколько сделал Майкрософт.
Вообще, тут, на мой взгляд, даже обсуждать не чего. Учитывая, что провадеры все транслируют в SQL, нужно поддерживать и константы, и ссылки на поля для всех типов поддерживаемых SQL-серверами. Можем сериализовать в SQL? Значит надо поддерживать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>"Хорошая" позиция.
Моя позиция простая — я тихо и без криков признал, что это баг и быстренько его пофиксил. Чем тебя не устраивает такая позиция?
IT>>А сколько ты их проверял? VD>Столько сколько сделал Майкрософт.
Т.е. ровно один — Linq 2 SQL.
VD>Вообще, тут, на мой взгляд, даже обсуждать не чего. Учитывая, что провадеры все транслируют в SQL, нужно поддерживать и константы, и ссылки на поля для всех типов поддерживаемых SQL-серверами. Можем сериализовать в SQL? Значит надо поддерживать.
Так вот, те провайдер(ы), которые ты тестировал в константы вообще ничего не транслируют, а на каждый чих создают параметр. Т.е. если написать table.Field == 1, то в SQL ты получишь table.Field = @param1. Поэтому, у такого провайдера подобного баг быть не может в принципе. Но правильным ли является такой подход? Вот в чём вопрос.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Моя позиция простая — я тихо и без криков признал, что это баг и быстренько его пофиксил. Чем тебя не устраивает такая позиция?
Такая позиция меня устаревает. Не ясно только тогда зачем были нужны высказывания в духе "в ЦЛР нет...".
IT>Так вот, те провайдер(ы), которые ты тестировал в константы вообще ничего не транслируют,
Провайдеры вообще не должны ничего траслировать. Их задача читать деревья выражений и герерить SQL.
IT>а на каждый чих создают параметр. Т.е. если написать table.Field == 1, то в SQL ты получишь table.Field = @param1. Поэтому, у такого провайдера подобного баг быть не может в принципе. Но правильным ли является такой подход? Вот в чём вопрос.
С полями разговор отдельный. Мы ведь говорили о значениях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Моя позиция простая — я тихо и без криков признал, что это баг и быстренько его пофиксил. Чем тебя не устраивает такая позиция? VD>Такая позиция меня устаревает. Не ясно только тогда зачем были нужны высказывания в духе "в ЦЛР нет...".
Потому что это на самом деле так. В CLR нельзя создать константу типа Guid.
IT>>Так вот, те провайдер(ы), которые ты тестировал в константы вообще ничего не транслируют, VD>Провайдеры вообще не должны ничего траслировать. Их задача читать деревья выражений и герерить SQL.
Так вот, те провайдер(ы), которые ты тестировал константы в SQL вообще не генерируют.
IT>>а на каждый чих создают параметр. Т.е. если написать table.Field == 1, то в SQL ты получишь table.Field = @param1. Поэтому, у такого провайдера подобного баг быть не может в принципе. Но правильным ли является такой подход? Вот в чём вопрос.
VD>С полями разговор отдельный. Мы ведь говорили о значениях.
'1' — это и есть значение, которое L2S преобразует в параметр.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Потому что это на самом деле так. В CLR нельзя создать константу типа Guid.
Несомненно. Только к делу не относится.
IT>Так вот, те провайдер(ы), которые ты тестировал константы в SQL вообще не генерируют. IT>...'1' — это и есть значение, которое L2S преобразует в параметр.
В этом есть свой резон. Но опять же мо не об этом говорим.
ЗЫ
Вдумайся. В шарпе есть всего несколько типов кроторые переврдятся с литералы. Зачем тогда в Expression.Conctant воспользовалисс object-ом, а не сделоло несколько перегрузок, как сделали с функциях вроде Sum?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вдумайся. В шарпе есть всего несколько типов кроторые переврдятся с литералы. Зачем тогда в Expression.Conctant воспользовалисс object-ом, а не сделоло несколько перегрузок, как сделали с функциях вроде Sum?
Почему object? Хотя бы потому что null — это тоже константа.
Если нам не помогут, то мы тоже никого не пощадим.
Я же написал, что метод сравнения експрешенов в тулките интернал. Поэтому проявить баг можно только в боевом режиме.
Если нам не помогут, то мы тоже никого не пощадим.
