Здравствуйте, Sinclair, Вы писали:
S>Здесь не вполне ясно, что имеется в виду. Такого синтаксиса в природе не существует.
Ну так уж не придирайся. Я не знаю как записать такой delete в Linq. Проблема вполне понятна. GZ>>Уже мы обязаны проверять является ли студент удаленным, или не удаленным. S>Не понятно, что значит "проверить". Результат любого запроса однозначно определяется историей всех предыдущих (в том смысле, который задан уровнем изоляции текущей транзакции) запросов.
Вот в данном случае и непонятен этот результат. То ли то вернет, то ли нет. Для Linq for objects — одно вернет. Для Linq for sql — второе. S>Поскольку никакого lazy load не предполагается, речь идет только о том, чтобы а) подготовить predicate-based delete statement и b) детерминированно его выполнить.
Детерменировано выполнить в рамках контекста. Ибо все запросы выполняются в рамках контекста и несут за собой явную/неявную транзакцию. Человечество потратило столько сил и усилий, чтобы транзакция выполнялось с вполне понятными правилами.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Lloyd, Вы писали:
L>>А как определить, что конкретный петя подпадает под это условие? Что если список оценок на клиента еще не загружен? S>Не надо ничего загружать. Нужно просто сконвертировать linq запрос в sql запрос и передать на сервер для выполнения.
Предположим, что у нас есть класс "Группа", у которой есть свойство-коллекция "Студенты". Что должно произойти с содержимым этой поллекции при удалении студента не напрямую, а опосредованно, через delete-запрос?
Здравствуйте, VladD2, Вы писали:
L>>Под обновлять ручками я имел в виду, не изменение исходников, которые генерит кастом тул, а изменение объектов в диаграме, там настроек уже не так много.
VD>Откровенно говоря, товарищь прав в том, что дизайнер и кодогенераторы (а по мне так и весь подход) студии кривоваты. Но надо все же понимать разницу между самим LINQ и визуальными средствами его поддержки.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Являются частью стандарта. Но вопрос в следующем. Когда мы выполняем delete * from students s where (select min(mark) from exam where exam.studentID = s.id) < 3 мы попадаем в классические грабли ORM. S>Ничего подобного. Если мы не пытаемся действовать в рамках безнадежно прогнившей концепции FBORM, то всё в порядке.
Здравствуйте, Lloyd, Вы писали:
RO>>Их же (переводчиков) мы должны благодарить за «перегруженные функции», «.NET программирование» и т. п. L>А что не так с перегруженными функциями?
Поиск не работает, где-то здесь было обсуждение, суть которого сводилась к тому, что в начале 1990-х в издательстве «Мир» был составлен хорошо продуманный терминологический словарь для ИТ. Там, в частности, понятие «overloaded function» переводилось как «совмещенные функции», что куда ближе к русскому языку. А потом издательства пришли за самыми дешевыми и быстрыми переводчиками, и те попереводили всё буквально.
Конечно, неприятнее всего видеть английский порядок слов в русских предложениях. Например, «IMAP server» — «Internet Mail Access Protocol server» — это всё существительные. По-русски мы почему-то не говорим «интернет почта доступ протокол сервер», но «IMAP сервер» — сплошь и рядом.
Здравствуйте, nikov, Вы писали:
RO>>Во-первых, не издевайтесь над Трёльсеном (не знаю, хорошо ли он пишет, но всё равно нечего перевирать имя).
N>Все претензии — к издателям. После того, как книга издана, упоминать в разговоре именно то написание фамилии автора, которое укзано на обложке — это вполне нормально. А если где-то нужно вставить ссылку на русское издание в списке литературы, то это будет единственным правильным способом указать фамилию автора.
Какая именно?
Он написал не одну, и российские издательства использовали разные написания.
Здравствуйте, Roman Odaisky, Вы писали:
L>>А что не так с перегруженными функциями?
RO>Поиск не работает, где-то здесь было обсуждение, суть которого сводилась к тому, что в начале 1990-х в издательстве «Мир» был составлен хорошо продуманный терминологический словарь для ИТ. Там, в частности, понятие «overloaded function» переводилось как «совмещенные функции», что куда ближе к русскому языку. А потом издательства пришли за самыми дешевыми и быстрыми переводчиками, и те попереводили всё буквально.
Ты считаешь что "совмещенные" в данном случае лучше чем "перегруженные"?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, MxKazan, Вы писали:
GZ>>>Зачем тебе эти тапочки? Нужен SQL — юзай sql. Linq for SQL — Linq. Зачем замешивать — незамешиваемое и вываливать наверх закамуфлированные проблемы несовместимости.
MK>>Ну вот очень огорчает, что Linq 2 SQL устраивает практически всем, но такой банальщины сделать не может
L>Ну насчет того что это банальщина, это ты загнул. Работа с DataContext подразумевает, что ты сначала меняешт объекты на клиенте. потом делаешь Submit и эти изменения уходят на сервер. Если в DataContext добавить предложенный вариант delete-а, это идиддическая картинка сразу рассыпается в прах.
Мы все-время рассуждаем в рамках того насколько это легко Linq'у.
Словно не он для меня создан, а я для него
Здравствуйте, Roman Odaisky, Вы писали:
N>>Все претензии — к издателям. После того, как книга издана, упоминать в разговоре именно то написание фамилии автора, которое укзано на обложке — это вполне нормально. А если где-то нужно вставить ссылку на русское издание в списке литературы, то это будет единственным правильным способом указать фамилию автора.
RO>Какая именно? RO>Он написал не одну, и российские издательства использовали разные написания.
На какую книгу ссылаешься, из той книги вариант написания фамилии автора и надо брать для ссылки.
Здравствуйте, Lloyd, Вы писали:
VD>>Откровенно говоря, товарищь прав в том, что дизайнер и кодогенераторы (а по мне так и весь подход) студии кривоваты. Но надо все же понимать разницу между самим LINQ и визуальными средствами его поддержки.
L>Только не надо про nemerle
Причем тут Немерле? Ты давно в отпуске то был?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, MxKazan, Вы писали:
MK>>Не-не-не, так дело не пойдёт. Есть конкретная задача, я её привел в теме, куда ведет ссылка. Прошу, выдайте мне решение. Я хочу удалить объекты из базы, просто по какому-то критерию.
VD>Один раз напиши процедуру удаления и впоследствии пользуйся ею.
Так и было сделано. На Linq в итоге легли только SELECT'ы, благо их было гораздо больше и это работало окейно.
VD>Ответить прямо? ОК, но не обижайся пожалуйста.
Да как-то и в мыслях не было.
VD>Ты не обладаешь достаточными знаниями, чтобы оценить то что тебе дали в руки. VD>Подробнее об этом написано здесь (Парадокс Блаба)
.
VD>Я могу только описать тебе те преимущества которые ты получишь после освоения функционального стиля программирования и понимания (осознания) всех концепций которые с ним связаны. VD>Освоив ФП ты сможешь писать код обработки коллекций в несколько раз более кратко. При этом код будет содержать в несколько раз меньше ошибок. Людям знакомые с ФП будет в несколько раз проще читать твой код, а значит его в несколько раз будет проще поддерживать. VD>Кроме того, если ты проникнешся функциональным подходом, то сможешь смотреть на решение многих задач подругому, на намного более абстрактном уровне.
Ну, откровенно говоря, как посмотришь на кучи сочетаний закорючек, которые приводят, например, здесь
, заявление про выигрышь в читабельности как-то гораздо сомнительнее выглядит. Когда поглядишь во что оно разворачивается, пищеварение совсем нарушается
VD>Для того чтобы воспользоваться преимуществами неизвестной тебе парадигмы нужно сделать немалое напряжение, чтобы понять ее. Проблема в том, что для этого обычно нужно менять мировозрение. Простые, казалось бы, концепции просто не втискиваются в рамки императивного мышления.
Вопрос то не в этом. Пока что большинство аргументов "за" выглядят примерно так: "появилась новая фича, значит она точно необходима и ей нужно пользоваться".
Не опровергая её необходимости, просто хотелось бы увидеть реальные примеры, в которых четко обозначено "было так, не нравилось потому то", "сделал по новому и это решило то-то".
VD>Практически для тебя (для таких как ты) я написал статью — VD>LINQ как шаг к функциональному программированию
. Прочитай ее когда она появится на сайте или если в твоих руках окажется 2-ой номер RSDN Magazine.
G>>>ЗЫ. Я подобное мнение видел у прожженых C++ников, которые впоследствие перешли на C#. MK>>Можно расслабиться и спокойно общаться. Мой профессиональный опыт — 3 года сплошного C#. Никакого C++.
VD>Откровенно говоря тем хуже для тебя. 3 года — это совсем малый срок для нашей профессии, а ты уже становишься ретроградом и отказываешься воспринимать новые (для тебя) знания.
Это, мягко говоря, неверная оценка — я лишь отношусь с подозрением и слушаю более опытных коллег, с которыми работаю.
И между прочим нигде
Здравствуйте, VladD2, Вы писали:
VD>>>Откровенно говоря, товарищь прав в том, что дизайнер и кодогенераторы (а по мне так и весь подход) студии кривоваты. Но надо все же понимать разницу между самим LINQ и визуальными средствами его поддержки.
L>>Только не надо про nemerle
VD>Причем тут Немерле? Ты давно в отпуске то был?
Переходить на личности тоже не надо.
P.S. В отпуске был в июле.
Здравствуйте, MxKazan, Вы писали:
MK>Мы все-время рассуждаем в рамках того насколько это легко Linq'у. MK>Словно не он для меня создан, а я для него
Он создан не для тебя, а для широких слоев населения. Linq for SQL — это концепция. Если бы это был чистый зайа, как говорил Антон, то такие массовые операции вполне подошли бы. Однако он берет на себя еще функцию обеспечения транзакции с помощью identity tracking, и это несколько более мощная концепция чем простой SQLBuilder.(ты ведь уже заметил несовместимость c identity tracking) И обеспечивает потребности более широких слоев населения. Если же сделать мусорку плохо совместимых концепций, то ничего хорошего не получится. Таких примеров — море.
Как и у любого универсального продукта, линка обладает недостатком. Если выходишь за границы концепции, то это потребует некоторых усилий. Так всегда было, и так всегда будет. Большинство путей обходов уже продуманы создателями и предоставлены интерфейсы. Так что по качеству универсализма, IMHO Linq for SQL продукт высшей пробы.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, MxKazan, Вы писали:
MK>>Мы все-время рассуждаем в рамках того насколько это легко Linq'у. MK>>Словно не он для меня создан, а я для него GZ>Он создан не для тебя, а для широких слоев населения. Linq for SQL — это концепция. Если бы это был чистый зайа, как говорил Антон, то такие массовые операции вполне подошли бы. Однако он берет на себя еще функцию обеспечения транзакции с помощью identity tracking, и это несколько более мощная концепция чем простой SQLBuilder.(ты ведь уже заметил несовместимость c identity tracking) И обеспечивает потребности более широких слоев населения. Если же сделать мусорку плохо совместимых концепций, то ничего хорошего не получится. Таких примеров — море. GZ>Как и у любого универсального продукта, линка обладает недостатком. Если выходишь за границы концепции, то это потребует некоторых усилий. Так всегда было, и так всегда будет. Большинство путей обходов уже продуманы создателями и предоставлены интерфейсы. Так что по качеству универсализма, IMHO Linq for SQL продукт высшей пробы.
Чего же стоит концепция, если она, упрощая одно, отягощает другое? Никогда бы не подумал, что сделать delete from where — это настолько сугубо индивидуальная задача, что на этот счет можно на заморачиваться ради концепции. Возможно Linq в целом — отличная идея. Однако, раз уж назвался Linq-to-Sql, так и занимайся Sql.
Здравствуйте, MxKazan, Вы писали:
MK>Чего же стоит концепция, если она, упрощая одно, отягощает другое? Никогда бы не подумал, что сделать delete from where — это настолько сугубо индивидуальная задача, что на этот счет можно на заморачиваться ради концепции. Возможно Linq в целом — отличная идея. Однако, раз уж назвался Linq-to-Sql, так и занимайся Sql.
Не. вы просто выделение неправильно сделали: Linq-to-Sql — это прежде всего Linq, т.е. язык запросов.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, MxKazan, Вы писали:
MK>>Чего же стоит концепция, если она, упрощая одно, отягощает другое? Никогда бы не подумал, что сделать delete from where — это настолько сугубо индивидуальная задача, что на этот счет можно на заморачиваться ради концепции. Возможно Linq в целом — отличная идея. Однако, раз уж назвался Linq-to-Sql, так и занимайся Sql.
L>Не. вы просто выделение неправильно сделали: Linq-to-Sql — это прежде всего Linq, т.е. язык запросов.
Не надо ко мне на вы, лучше на ты
Linq — концепция. Sql — назначение. Разве не так? Если бы он был как раз языком запросов, моей проблемы судя по всему бы не было
Здравствуйте, MxKazan, Вы писали:
L>>Не. вы просто выделение неправильно сделали: Linq-to-Sql — это прежде всего Linq, т.е. язык запросов.
MK>Не надо ко мне на вы, лучше на ты MK>Linq — концепция. Sql — назначение. Разве не так? Если бы он был как раз языком запросов, моей проблемы судя по всему бы не было
Почему не было бы? Linq — язык запросов, синтаксиса для update/delete у него нет
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, MxKazan, Вы писали:
L>>>Не. вы просто выделение неправильно сделали: Linq-to-Sql — это прежде всего Linq, т.е. язык запросов.
MK>>Не надо ко мне на вы, лучше на ты MK>>Linq — концепция. Sql — назначение. Разве не так? Если бы он был как раз языком запросов, моей проблемы судя по всему бы не было
L>Почему не было бы? Linq — язык запросов, синтаксиса для update/delete у него нет
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Lloyd, Вы писали:
L>>>А как определить, что конкретный петя подпадает под это условие? Что если список оценок на клиента еще не загружен? S>>Не надо ничего загружать. Нужно просто сконвертировать linq запрос в sql запрос и передать на сервер для выполнения.
L>Предположим, что у нас есть класс "Группа", у которой есть свойство-коллекция "Студенты". Что должно произойти с содержимым этой поллекции при удалении студента не напрямую, а опосредованно, через delete-запрос?
Это вполне можно оставить на разработчика. Если его будет интересовать состояние коллекции "Студенты", то он ее перечитает.
Здравствуйте, MxKazan, Вы писали:
L>>Предположим, что у нас есть класс "Группа", у которой есть свойство-коллекция "Студенты". Что должно произойти с содержимым этой поллекции при удалении студента не напрямую, а опосредованно, через delete-запрос?
MK>Это вполне можно оставить на разработчика. Если его будет интересовать состояние коллекции "Студенты", то он ее перечитает.
Я не знаю как записать такой delete в Linq. Проблема вполне понятна.
