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

I>Скажем, типичный пример — это c4 фильтр, он сам предложил задачу и сам же забраковал решение.

Учитель в школе тебе сам же предлагает задачу, сам же двойки ставит.
Все учителя злостные манипуляторы, по-твоему.


I>Может он ожидал, что Синклер сделает это через IQueryable.

Гадания на кофейной гуще.
Почти всегда переводят обсуждение в срач.


I>Но о своих ожиданиях он умолчал, уточнения он как правило игнорирует или начинает забалтывать, кривляться-стебаться, делать вид что непонимает и тд.

Он понимает достаточно, чтобы предположить — задёшево относительную адресацию в линке не сделаешь.
Не заточен потому что линк на это.


I>Вот, скажем, два года назад была речь про предкомпиляцию запросов в БД:

I>IT: "Предкомриляция запроса внутри БД делается самой БД без каких-либо телодвижений с клиента. Если ты о методе Prepare из ADO.NET, то он делается на открытом соединении и держать его открытым между вызовами не самая лучшая идея."

I>И вот как это прочёл наш герой:
I>alex_public: "В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы"

Выглядит так, что ты путаешь предкомпилённый запрос на стороне базы и предкомпиляённый запрос драйвера OleDbCommand.Prepare().
Это разные вещи.
Первый просто кеширует запрос (или не кеширует, или кеширует, но потом запрос из кеша улетает), второй на уровне драйвера делает следующее:
(1) производит валидацию типов аргументов локально;
(2) производит валидацию типов аргументов удалённо;
(3) производит валидацию/компиляцию самого запроса удалённо;
(4) сопоставляет клиентский запрос с соотв. предкомпиллированной версией на стороне сервака.

При последующих вызовах в серии их операции 1, 2, 3 и 4 уже не производятся.
Пока жив объект OleDbCommand, на закешированная версия запроса из кеша сервера вытеснена не будет.

Если же обсуждаемые ORM заточены на однократные вызовы запросов к БД, то им смысла в локальном prepare нет, разумеется.


I>Теперь прошло два года, и смотрим, чего поменялось. Речь про CTE:

I>IB: "есть ограничение языка, которое не позволяет записать рекурсивную лямбду. Есть обход этого ограничения но он грязный. Лямбды — это часть линка, следовательно, ограничения на лямбды, равно как и их обход, относятся в том числе и к линку. Никаких дополнительных ограничений у линка нет. Следовательно и проблема та же самая, и решение то же, и это не эксперимент, и это ограничение языка, а не непосредственно линка. "
I>Здесь речь про ограничение языка и характеристику обходного решение — "грязное". Здесь же явное утверждение, что linq ни при чем.

Если бы ты был сосредоточен не на словах, не на фигне навроде "а вот он такое-то говорил, бе-бе-бе", а на сути происходящего, ты бы обнаружил слудующее:
— ср-ва для обхода ограничения на рекурсию лямбд в языке есть — это известный Y-комбинатор.
— язык запросов linq вполне мог бы реализовать его прозрачно для программиста... но! даже этого не требуется!
— ввиду того, что лямбды унутре выполнены как обычные объекты-замыкания, Y-комбинатор не нужен, достаточно обычной рекурсии в методе такого объекта.
Шах и мат. ))

Всё это напомнило мне другой аналогичныйслучай — linq-rewrite, с ним носятся как с писанной торбой, мол, ОГО ФИЧА!!!
А что мешало реализовать её прямо в компиляторе?


I>Вот он или не понял, или продолжает кривляться. Но тут же сам и пишет, что CTE появилось только в одной библиотеке и задаётся вопросом "почему" ? Ему только что дали на это ответ

Как я только показал — никакой "ответ" не дали.
За такой "ответ" в школе двойки ставят сходу.


I>То ли товарищ вообще не читает, ни что сам пишет, ни что ему пишут, то ли не понимает, то ли специально кривляется и валяет дурака. Ну, как вариант, у него память ровно на текущее сообщение. Но это вобщем тоже показатель "адекватности"

Э, не, адекватность — это обратная сторона объективности.
Но пока что необъективными выглядят ваши аргументы.
Вам достаточно выйти из вашей странной позы и признать, да, вот здесь, здесь и здесь малость недоработано.
И вместо того, чтобы компосировать моск более объктивным "внешним наблюдателям", типа Алекса, лучше бы сходит в гитхаб на CoreFX и там озвучил бы свои пожелания одновременно с вполне конкретными техническими причинами (как я дал выше) почему твои пожелания вполне имеют право на жизнь.

Это будет адекватно.
Происходящее здесь замыливание "неудобных" моментов — нет.
Со стороны смотрится как тихий дурдом, как параллельная вселенная в сравнении с "обычной" инженерией.

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

I>Скажем, типичный пример — это c4 фильтр, он сам предложил задачу и сам же забраковал решение.

Учитель в школе тебе сам же предлагает задачу, сам же двойки ставит.
Все учителя злостные манипуляторы, по-твоему.


I>Может он ожидал, что Синклер сделает это через IQueryable.

Гадания на кофейной гуще.
Почти всегда переводят обсуждение в срач.


I>Но о своих ожиданиях он умолчал, уточнения он как правило игнорирует или начинает забалтывать, кривляться-стебаться, делать вид что непонимает и тд.

Он понимает достаточно, чтобы предположить — задёшево относительную адресацию в линке не сделаешь.
Не заточен потому что линк на это.


I>Вот, скажем, два года назад была речь про предкомпиляцию запросов в БД:

I>IT: "Предкомриляция запроса внутри БД делается самой БД без каких-либо телодвижений с клиента. Если ты о методе Prepare из ADO.NET, то он делается на открытом соединении и держать его открытым между вызовами не самая лучшая идея."

I>И вот как это прочёл наш герой:
I>alex_public: "В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы"

Выглядит так, что ты путаешь предкомпилённый запрос на стороне базы и предкомпиляённый запрос драйвера OleDbCommand.Prepare().
Это разные вещи.
Первый просто кеширует запрос (или не кеширует, или кеширует, но потом запрос из кеша улетает), второй на уровне драйвера делает следующее:
(1) производит валидацию типов аргументов локально;
(2) производит валидацию типов аргументов удалённо;
(3) производит валидацию/компиляцию самого запроса удалённо;
(4) сопоставляет клиентский запрос с соотв. предкомпиллированной версией на стороне сервака.

При последующих вызовах в серии их операции 1, 2, 3 и 4 уже не производятся.
Пока жив объект OleDbCommand, закешированная версия запроса из кеша сервера вытеснена не будет.

Если же обсуждаемые ORM заточены на однократные вызовы запросов к БД, то им смысла в локальном prepare нет, разумеется.


I>Теперь прошло два года, и смотрим, чего поменялось. Речь про CTE:

I>IB: "есть ограничение языка, которое не позволяет записать рекурсивную лямбду. Есть обход этого ограничения но он грязный. Лямбды — это часть линка, следовательно, ограничения на лямбды, равно как и их обход, относятся в том числе и к линку. Никаких дополнительных ограничений у линка нет. Следовательно и проблема та же самая, и решение то же, и это не эксперимент, и это ограничение языка, а не непосредственно линка. "
I>Здесь речь про ограничение языка и характеристику обходного решение — "грязное". Здесь же явное утверждение, что linq ни при чем.

Если бы ты был сосредоточен не на словах, не на фигне навроде "а вот он такое-то говорил, бе-бе-бе", а на сути происходящего, ты бы обнаружил слудующее:
— ср-ва для обхода ограничения на рекурсию лямбд в языке есть — это известный Y-комбинатор.
— язык запросов linq вполне мог бы реализовать его прозрачно для программиста... но! даже этого не требуется!
— ввиду того, что лямбды унутре выполнены как обычные объекты-замыкания, Y-комбинатор не нужен, достаточно обычной рекурсии в методе такого объекта.
Шах и мат. ))

Всё это напомнило мне другой аналогичныйслучай — linq-rewrite, с ним носятся как с писанной торбой, мол, ОГО ФИЧА!!!
А что мешало реализовать её прямо в компиляторе?


I>Вот он или не понял, или продолжает кривляться. Но тут же сам и пишет, что CTE появилось только в одной библиотеке и задаётся вопросом "почему" ? Ему только что дали на это ответ

Как я только показал — никакой "ответ" не дали.
За такой "ответ" в школе двойки ставят сходу.


I>То ли товарищ вообще не читает, ни что сам пишет, ни что ему пишут, то ли не понимает, то ли специально кривляется и валяет дурака. Ну, как вариант, у него память ровно на текущее сообщение. Но это вобщем тоже показатель "адекватности"

Э, не, адекватность — это обратная сторона объективности.
Но пока что необъективными выглядят ваши аргументы.
Вам достаточно выйти из вашей странной позы и признать, да, вот здесь, здесь и здесь малость недоработано.
И вместо того, чтобы компосировать моск более объктивным "внешним наблюдателям", типа Алекса, лучше бы сходит в гитхаб на CoreFX и там озвучил бы свои пожелания одновременно с вполне конкретными техническими причинами (как я дал выше) почему твои пожелания вполне имеют право на жизнь.

Это будет адекватно.
Происходящее здесь замыливание "неудобных" моментов — нет.
Со стороны смотрится как тихий дурдом, как параллельная вселенная в сравнении с "обычной" инженерией.