Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Да всё понятно теперь. ))) Просто только приперев тебя к стенке удалось выяснить, что реально тебе нужны совсем не динамические запросы. А как раз классические статические, но конструируемые по частям.
НС>Мне вот интересно — ты действительно не понимаешь или усиленно прикидываешься? Типичный код:
НС>

НС>var query = db.MyTable;
НС>if (someCondition)
НС>    query = query.Where(m => m.SomeRef.Foo > 4);
НС>var data = query.Select(m => new {m.X, m.Y});
НС>

НС>Ты как, в состоянии понять что при срабатывании условия запрос не просто будет немножечко дописан, он будет другой — в нем появится джойн?
НС>И это самый простейший случай, когда у тебя все в одном методе. В реальности 1 строчка может быть в одном слое и даже отдельной dll, а 2 и 3 — в другом.

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

1) Запросы статические по сути, но сконструированные из нескольких частей, возможно даже в разных функциях.
2) Статические запросы построенные через динамическую композицию — статические части запроса комбинируются разными способами в зависимости от runtime условий (то есть расширение пункта 1).
3) Динамические запросы — имена полей, таблиц, выражения условий и т.п. не известны на этапе компиляции.
4) Стирание полного типа запроса — это позволяет частично отличающимся запросам иметь одинаковый тип. Степень отличия контролируется тем, насколько стёрт тип.
5) Конструирование частей запросов в разных динамических библиотеках. Вообще говоря это ортогонально пунктам 1-4 и работает для из них.

Из всего этого только 3) и 4) мешают полностью сгенерировать текст запроса во время компиляции.
Вариант 3) нужен очень редко, и убивает возможность части статических проверок — что в LINQ'е, что в любом другом EDSL.
Насколько я вижу, 4) тоже далеко не всегда необходим. Причём предпосылок/аргументов к его необходимости в этом топике я не увидел.

При этом в этой ветке упор в основном делался на 1) и на 2) — вполне резонно, но это прекрасно резульзуется и в compile-time EDSL.
Помимо этого, мимоходом зачем-то кидаются запросы по 5) (попытка хоть как-то выкрутится?), хотя видимо подразумевалось 4)

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Да всё понятно теперь. ))) Просто только приперев тебя к стенке удалось выяснить, что реально тебе нужны совсем не динамические запросы. А как раз классические статические, но конструируемые по частям.
НС>Мне вот интересно — ты действительно не понимаешь или усиленно прикидываешься? Типичный код:
НС>

НС>var query = db.MyTable;
НС>if (someCondition)
НС>    query = query.Where(m => m.SomeRef.Foo > 4);
НС>var data = query.Select(m => new {m.X, m.Y});
НС>

НС>Ты как, в состоянии понять что при срабатывании условия запрос не просто будет немножечко дописан, он будет другой — в нем появится джойн?
НС>И это самый простейший случай, когда у тебя все в одном методе. В реальности 1 строчка может быть в одном слое и даже отдельной dll, а 2 и 3 — в другом.

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

1) Запросы статические по сути, но сконструированные из нескольких частей, возможно даже в разных функциях.
2) Статические запросы построенные через динамическую композицию — статические части запроса комбинируются разными способами в зависимости от runtime условий (то есть расширение пункта 1).
3) Динамические запросы — имена полей, таблиц, выражения условий и т.п. не известны на этапе компиляции.
4) Стирание полного типа запроса — это позволяет частично отличающимся запросам иметь одинаковый тип. Степень отличия контролируется тем, насколько стёрт тип.
5) Конструирование частей запросов в разных динамических библиотеках. Вообще говоря это ортогонально пунктам 1-4 и работает для каждого из них.

Из всего этого только 3) и 4) мешают полностью сгенерировать текст запроса во время компиляции.
Вариант 3) нужен очень редко, и убивает возможность части статических проверок — что в LINQ'е, что в любом другом EDSL.
Насколько я вижу, 4) тоже далеко не всегда необходим. Причём предпосылок/аргументов к его необходимости в этом топике я не увидел.

При этом в этой ветке упор в основном делался на 1) и на 2) — вполне резонно, но это прекрасно резульзуется и в compile-time EDSL.
Помимо этого, мимоходом зачем-то кидаются запросы по 5) (попытка хоть как-то выкрутится?), хотя видимо подразумевалось 4)