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

RO>Во-первых, не издевайтесь над Трёльсеном (не знаю, хорошо ли он пишет, но всё равно нечего перевирать имя).

Все претензии — к издателям. После того, как книга издана, упоминать в разговоре именно то написание фамилии автора, которое укзано на обложке — это вполне нормально. А если где-то нужно вставить ссылку на русское издание в списке литературы, то это будет единственным правильным способом указать фамилию автора.

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

RO>Фамилия у него, насколько я понимаю, датского происхождения (Trølsen).

Кстати, я живу в Дании, и могу сказать, что в русском языке нет буквы точно передающей датское 'ø'. Самым похожим аналогом мне кажется именно 'oe', при условии если произносить их очень слитно, не как 'о-йе'.

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

MK>Отсутствие продакшн-опыта на нативном языке не означает непонимание основных принципов и неумение программировать на нём.

Более правдоподобным выглядит утвеждение: "Наличие продакшн-опыта на нативном языке не означает понимания основных принципов и умения программировать на нем". Вне зависимости от "нативного языка".

MK>Такое вот оно новое поколение, не стесняется

Это свойственно всем новым поколениям.

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

S>Здравствуйте, gandjustas, Вы писали:
G>>А можно ли использовать все возможности запросов в операторе delete?
S>Да. Всю мощь SQL.
Всю-всю-всю? И даже каскадные удаления тоже?
Зачем тебе эти тапочки? Нужен SQL — юзай sql. Linq for SQL — Linq. Зачем замешивать — незамешиваемое и вываливать наверх закамуфлированные проблемы несовместимости.

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

G>>>А можно ли использовать все возможности запросов в операторе delete?
S>>Да. Всю мощь SQL.
GZ>Всю-всю-всю? И даже каскадные удаления тоже?

Каскадные удаления не являются частью SQL-я.

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

GZ>Здравствуйте, Sinclair, Вы писали:
GZ>Зачем тебе эти тапочки? Нужен SQL — юзай sql. Linq for SQL — Linq. Зачем замешивать — незамешиваемое и вываливать наверх закамуфлированные проблемы несовместимости.

Ну вот очень огорчает, что Linq 2 SQL устраивает практически всем, но такой банальщины сделать не может

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

GZ>>Зачем тебе эти тапочки? Нужен SQL — юзай sql. Linq for SQL — Linq. Зачем замешивать — незамешиваемое и вываливать наверх закамуфлированные проблемы несовместимости.

MK>Ну вот очень огорчает, что Linq 2 SQL устраивает практически всем, но такой банальщины сделать не может

Ну насчет того что это банальщина, это ты загнул. Работа с DataContext подразумевает, что ты сначала меняешт объекты на клиенте. потом делаешь Submit и эти изменения уходят на сервер. Если в DataContext добавить предложенный вариант delete-а, это идиддическая картинка сразу рассыпается в прах.

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

L>Каскадные удаления не являются частью SQL-я.
Являются частью стандарта. Но вопрос в следующем. Когда мы выполняем delete * from students s where (select min(mark) from exam where exam.studentID = s.id) < 3 мы попадаем в классические грабли ORM. Мы положили на валидацию. Мы не можем сказать какой объект student был уже удален. И мы не можем сказать ваще какие объекты удалены и насколько у нас актуальные данные в памяти поскольку есть триггеры и каскадные удаления. По факту классическая рассинхронизация оперативной памяти и состояния на БД. Подобный запрос только увеличит глубину падения в наших глубинах.
Да и тогда надо вообще ввести генерацию truncate table. Для полноты картины.

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

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

L>>Каскадные удаления не являются частью SQL-я.
GZ>Являются частью стандарта.

Но не являются частью языка. А речь о нем.

GZ>Но вопрос в следующем. Когда мы выполняем delete * from students s where (select min(mark) from exam where exam.studentID = s.id) < 3 мы попадаем в классические грабли ORM. Мы положили на валидацию. Мы не можем сказать какой объект student был уже удален. И мы не можем сказать ваще какие объекты удалены и насколько у нас актуальные данные в памяти поскольку есть триггеры и каскадные удаления. По факту классическая рассинхронизация оперативной памяти и состояния на БД. Подобный запрос только увеличит глубину падения в наших глубинах.

+1000!

RO>Как бы то ни было, «Troelsen» ни при каких обстоятельствах не произносится ни как «Тройелсен», ни как «Троэлсен». Ты же сам употребил слово «транскрипция», хотя «Троелсен» — это транслитерация, а не транскрипция. Почему «Эндрю», а не «Андрев»?

Т.е. проблема в двойной транслитерации — сначала на английский, а потом на русский.

Здравствуйте, GlebZ, Вы писали:
GZ>Зачем тебе эти тапочки? Нужен SQL — юзай sql. Linq for SQL — Linq. Зачем замешивать — незамешиваемое и вываливать наверх закамуфлированные проблемы несовместимости.
Очень странная позиция. Вот есть у нас офигенная штука — ЗАпросы Интегрированные в Язык, ЗАИЯ. Преимущества перед SQL вроде бы понятны: статический контроль компилятора, интеллисенс, рефакторинг.
И что, при переходе от select к delete у нас потребности в этих преимуществах внезапно исчезают? Что за фокусы, маэстро, верните зайца обратно!

Вторая претензия у меня именно к "замешиванию незамешиваемого": я правильно понимаю, что предлагается для select, а также одиночных инсертов/апдейтов использовать Linq, а все остальные запросы выполнять на SQL? И всё это в рамках одного приложения? Или имеется в виду, что при первом же появлении delete statement нужно немедленно наложить на себя аскезу, переписать всё на SQL, а арсенал готового кода на linq безвозмездно передать в казну? Надо полагать, теперь он долго не протянет (с).

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

GZ>Являются частью стандарта. Но вопрос в следующем. Когда мы выполняем delete * from students s where (select min(mark) from exam where exam.studentID = s.id) < 3 мы попадаем в классические грабли ORM.
Ничего подобного. Если мы не пытаемся действовать в рамках безнадежно прогнившей концепции FBORM, то всё в порядке.
GZ>Мы положили на валидацию. Мы не можем сказать какой объект student был уже удален.
Почему? Можем. У нас удалены все объекты, у которых минимальная оценка меньше тройки.
GZ>И мы не можем сказать ваще какие объекты удалены и насколько у нас актуальные данные в памяти поскольку есть триггеры и каскадные удаления.
Совершенно верно. Актуальность данных в памяти — зловредная штука, полагаться на нее нельзя. Программисты на plain old SQL и Lightweight ORM об этом подсознательно помнят всегда: данные — одноразовая штука, а не магически обновляемый образ своего прототипа.
А вот пользователи FBORM пытаются полагаться на состояние кэша, что крайне противопоказано по медицинским соображениям.

GZ>По факту классическая рассинхронизация оперативной памяти и состояния на БД. Подобный запрос только увеличит глубину падения в наших глубинах.
Поэтому нужно восстать из зада и перестать слепо полагаться на кэш вообще. Идеология, где каждый объект для убийства нужно тащить целиком в память (как, впрочем, и для изменения) — глубоко порочна по своей природе.

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

GZ>>Мы положили на валидацию. Мы не можем сказать какой объект student был уже удален.
S>Почему? Можем. У нас удалены все объекты, у которых минимальная оценка меньше тройки.

А как определить, что конкретный петя подпадает под это условие? Что если список оценок на клиента еще не загружен?

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

MK>Не-не-не, так дело не пойдёт. Есть конкретная задача, я её привел в теме, куда ведет ссылка. Прошу, выдайте мне решение. Я хочу удалить объекты из базы, просто по какому-то критерию.

Один раз напиши процедуру удаления и впоследствии пользуйся ею.

IT>>>>2. linq 2 objects принципиально изменил способы обработки данных в памяти.
MK>>>Так. Я видимо не в теме. А что принципиального нового linq 2 objects внёс по части "способы обработки данных в памяти"?

IT>>>>3. Возможность работать в функциональном стиле с человеческим лицом.
MK>>>Честно говоря, никогда не страдал от отсутствия подобного в C#

G>>Вы действительно не в тебе, были бы в теме — оценили бы преимущества.
MK>Отмахнуться — это удобно. А ответить на вопрос?

Ответить прямо? ОК, но не обижайся пожалуйста.
Ты не обладаешь достаточными знаниями, чтобы оценить то что тебе дали в руки.
Подробнее об этом написано здесь (Парадокс Блаба)

Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.

.

Я могу только описать тебе те преимущества которые ты получишь после освоения функционального стиля программирования и понимания (осознания) всех концепций которые с ним связаны.
Освоив ФП ты сможешь писать код обработки коллекций в несколько раз более кратко. При этом код будет содержать в несколько раз меньше ошибок. Людям знакомые с ФП будет в несколько раз проще читать твой код, а значит его в несколько раз будет проще поддерживать.
Кроме того, если ты проникнешся функциональным подходом, то сможешь смотреть на решение многих задач подругому, на намного более абстрактном уровне.

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

Практически для тебя (для таких как ты) я написал статью —
LINQ как шаг к функциональному программированию

Автор(ы): Чистяков Влад (VladD2)
Дата: 28.08.2008
Цель данной статьи – объяснить читателю незнакомому с ФП, что такое функциональный подход, какие он дает преимущества, и как его можно использовать с помощью LINQ и C# 3.0.
Кроме того, эта статья дает некоторое понимание того, как работает «LONQ to Object» и на каких принципах он основан.

. Прочитай ее когда она появится на сайте или если в твоих руках окажется 2-ой номер RSDN Magazine.

G>>ЗЫ. Я подобное мнение видел у прожженых C++ников, которые впоследствие перешли на C#.
MK>Можно расслабиться и спокойно общаться. Мой профессиональный опыт — 3 года сплошного C#. Никакого C++.

Откровенно говоря тем хуже для тебя. 3 года — это совсем малый срок для нашей профессии, а ты уже становишься ретроградом и отказываешься воспринимать новые (для тебя) знания.

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

G>>>ЗЫ. Я подобное мнение видел у прожженых C++ников, которые впоследствие перешли на C#.
MK>>Можно расслабиться и спокойно общаться. Мой профессиональный опыт — 3 года сплошного C#. Никакого C++.

E>Вот и выросло новое поколение

Спокойно! Оно просто еще растет. К тому же не стоит судить обо всех по одному человеку.

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

Нее. Все хуже. По факту мы не можем полагаться даже на контекст транзакции.

var d=delete * from students s where (select min(mark) from exam where exam.studentID = s.id) < 3
....
var s=select * from students
...
context.Submit();

Уже мы обязаны проверять является ли студент удаленным, или не удаленным. Но трабла в том, что это и почти невозможно проверить. Поскольку нам придется генерить select в соответсвии с правилами delete. А если мы еще до начала изменили сам exam — то ваще невозможно.

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

MK>>Дык он там генерит массу всего! Боюсь, что поправив ручками, что нибудь да пропущу

L>Под обновлять ручками я имел в виду, не изменение исходников, которые генерит кастом тул, а изменение объектов в диаграме, там настроек уже не так много.

Откровенно говоря, товарищь прав в том, что дизайнер и кодогенераторы (а по мне так и весь подход) студии кривоваты. Но надо все же понимать разницу между самим LINQ и визуальными средствами его поддержки.

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

L>А как определить, что конкретный петя подпадает под это условие? Что если список оценок на клиента еще не загружен?
Не надо ничего загружать. Нужно просто сконвертировать linq запрос в sql запрос и передать на сервер для выполнения.

Здравствуйте, GlebZ, Вы писали:
GZ>Нее. Все хуже. По факту мы не можем полагаться даже на контекст транзакции.
GZ>

GZ>var d=delete * from students s where (select min(mark) from exam where exam.studentID = s.id) < 3
GZ>....
GZ>var s=select * from students
GZ>...
GZ>context.Submit();
GZ>

Здесь не вполне ясно, что имеется в виду. Такого синтаксиса в природе не существует.
GZ>Уже мы обязаны проверять является ли студент удаленным, или не удаленным.
Не понятно, что значит "проверить". Результат любого запроса однозначно определяется историей всех предыдущих (в том смысле, который задан уровнем изоляции текущей транзакции) запросов. Поскольку никакого lazy load не предполагается, речь идет только о том, чтобы а) подготовить predicate-based delete statement и b) детерминированно его выполнить.

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

S>Очень странная позиция. Вот есть у нас офигенная штука — ЗАпросы Интегрированные в Язык, ЗАИЯ. Преимущества перед SQL вроде бы понятны: статический контроль компилятора, интеллисенс, рефакторинг.
S>И что, при переходе от select к delete у нас потребности в этих преимуществах внезапно исчезают? Что за фокусы, маэстро, верните зайца обратно!

Зайца бросила хозяйка,
Под мостом остался зайка.

Я совершенно против чтобы из зайца делали бегемота с непонятной мне целью. Ты кстати назвал очень интересное преимущество называемое "рефакторинг". А это означает что сам запрос может быть размазан по коду и инкапсулирован в функции которые не показывают как именно делается запрос. И это налагает обязательства.
Селективные запросы вполне совместимы с такой идеалогией, поскольку мы вполне можем с помощью Identity гарантировать житие транзакции. А вот ежели мы впендюриваемся в запросы без Identity — мы усложняем не только само Linq, но и себе жизнь. Притом на порядок. От этого больше вреда чем пользы.

S>Вторая претензия у меня именно к "замешиванию незамешиваемого": я правильно понимаю, что предлагается для select, а также одиночных инсертов/апдейтов использовать Linq, а все остальные запросы выполнять на SQL? И всё это в рамках одного приложения? Или имеется в виду, что при первом же появлении delete statement нужно немедленно наложить на себя аскезу, переписать всё на SQL, а арсенал готового кода на linq безвозмездно передать в казну? Надо полагать, теперь он долго не протянет (с).
Цезарю — цезарево, авгию — авгиево. Для массированной обработки данных есть процедуры. Не вмещаешься в предложенную концепцию — выходи за пределы. Только вводить такие запросы — это гадить на саму концепцию.