Re[21]: Давайте поговорим о c# 3.0
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.09.08 03:27
Оценка: +1
Здравствуйте, GlebZ, Вы писали:
GZ>Я совершенно против чтобы из зайца делали бегемота с непонятной мне целью. Ты кстати назвал очень интересное преимущество называемое "рефакторинг". А это означает что сам запрос может быть размазан по коду и инкапсулирован в функции которые не показывают как именно делается запрос. И это налагает обязательства.
GZ>Селективные запросы вполне совместимы с такой идеалогией, поскольку мы вполне можем с помощью Identity гарантировать житие транзакции. А вот ежели мы впендюриваемся в запросы без Identity — мы усложняем не только само Linq, но и себе жизнь. Притом на порядок. От этого больше вреда чем пользы.
Поток сознания не понял.

GZ>Цезарю — цезарево, авгию — авгиево. Для массированной обработки данных есть процедуры.

GZ>Не вмещаешься в предложенную концепцию — выходи за пределы.
По прежнему продолжаю непонимать, почему граница рисуется между select и всеми остальными. Мне что, сложные селекты тоже писать "на процедурах"?

На всякий случай напомню, что могучесть линка в частности в том, что обеспечивается эффект динамического построения запросов при соблюдении статического контроля корректности. Типа
var q = from ... where ... select  ...
if (somecondition)
{
  q = from q where AdditionalPredicate select ... 
}

И эта техника равно применима ко всем типам запросов. Почему я не могу сначала построить нетривиальный select, а затем скормить его на вход insert'у не вытаскивая данные из SQL сервера?

GZ>Только вводить такие запросы — это гадить на саму концепцию.

Не надо вот этих вот копротерминов. Если ваше понимание концепции не совпадает с моим, то не нужно думать, что мое чем-то хуже.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[25]: Давайте поговорим о c# 3.0
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.09.08 04:17
Оценка:
Здравствуйте, Lloyd, Вы писали:
L>Предположим, что у нас есть класс "Группа", у которой есть свойство-коллекция "Студенты".
L>Что должно произойти с содержимым этой поллекции при удалении студента не напрямую, а опосредованно, через delete-запрос?
А с чего что-то должно происходить с классами при удалении объектов?
Если тебя интересует, что произойдет с экземплярами этих классов, то ответ — ничего.
Потому, что эти экземпляры были подняты в память в рамках некоторого запроса; и они актуальны на момент выполнения этого запроса.

Тебя же не беспокоит, что DataTable, зачитанный десять минут назад, не обновляется автомагически оттого, что где-то еще (может быть в другом потоке, в другой транзакции, да и вообще в другом приложении) была выполнена модифицирующая операция? А почему тебя беспокоят студенты и группы?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[25]: Давайте поговорим о c# 3.0
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.09.08 04:17
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Ну так уж не придирайся. Я не знаю как записать такой delete в Linq. Проблема вполне понятна.

Проблема — непонятна.

GZ>Вот в данном случае и непонятен этот результат. То ли то вернет, то ли нет. Для Linq for objects — одно вернет. Для Linq for sql — второе.

Не понимаю. Должно всегда возвращаться одно и то же. Если не одно и то же — это баг в реализации.

S>>Поскольку никакого lazy load не предполагается, речь идет только о том, чтобы а) подготовить predicate-based delete statement и b) детерминированно его выполнить.

GZ>Детерменировано выполнить в рамках контекста.
Это очевидно. Контекст влияет только на понятие "очередности", которое я упомянул выше. Т.е. мы можем (и должны) полагаться на то, что
а) последующий select запрос в том же контексте будет учитывать эффект от удаления
б) последующие результаты в других контекстах будут либо учитывать, либо не учитывать эффект от удаления в зависимости от их уровня изоляции

Для Linq to objects можно считать, что уровень изоляции всегда dirty read.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[42]: Давайте поговорим о c# 3.0
От: Lloyd Россия  
Дата: 23.09.08 07:02
Оценка: 3 (1)
Здравствуйте, Константин Л., Вы писали:

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


КЛ>[]


КЛ>что в линке под айдентити подразумевается


подразумевается, что объект с заданным ключом будет существовать в пределах DataContext-а в единственном экземпляре, вне звисимости от того, через какое кол-во запросов он выл возвращен.
from c in context.Customers select c будет содержать from c in context.Customers where c.ID = 1 select c
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[11]: Давайте поговорим о c# 3.0
От: MxKazan Россия  
Дата: 23.09.08 08:32
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>>>В некотором смысле первый. Дело в том, что преобразованием имени класса в имя поля теперь занимается сам компилятор. Ранее это был ручной или генерируемый код.

MK>>А какая в сущности разница?

IT>Комрилятор знает больше. Сгенерированная строковая константа для компилятора всё так же остаётся константой. А поле/свойство класса — это ещё и принадлежность к определённому классу. В принципе, precompile-time генератция может многое, но у неё свои козявки. Идеал же вообще ещё не достигнут, но уже возможен. Так, например, уже сегодня вполне возможно на Немерле генерировать необходимую метаинформацию непосредственно из БД в компайл-тайм

Гм... какая-то безграничная любовь у многих вас к Немерле. Не сотвори себе кумира

MK>>Намёк ясен. Но он не совсем применим к Linq-To-Sql, уж слишком специфично, я написал чего не хватает. Видно и Microsoft это понимает, потому и есть Entity Framework. А проблема с DELETE похоже не имеет простого решения.


IT>По мне, так EF — это чистый маркетинг. Наш ответ Хайберлену. Есть же в конце концов и другие невостребованные технологии у MS вроде того же WWF. Будет ещё одна.

Я её еще не пробовал, только статейки посмотрел. Она в чем-то схожа с фреймворком фирмы, о которой уже писал. У них давно решено и то, что в Linq-to-Sql зовется identity и типизация строгая (но генераторами, да) и простые скрипты можно формировать в терминах бизнес-объектов, но не имея самих объектов в памяти. Это я к тому, что возможно Linq-to-Sql меня не столь радует из-за более раннего знакомства с, на мой взгляд, более сильной технологией. Надеюсь в будущих версиях, Майкрософт всё же улучшит Sql'ную составляющую Линка, допустив при желании его использование именно как генератора.

IT>>>Linq 2 Objects внёс декларативность. Т.е. теперь я пишу что я хочу получить, а не как. В результате вместо кучи циклов с перебором списков и словарей у меня декларативная конструкция.

MK>>Это понятно, про ФП я читал. Но не очень понятно в чем конкретная новизна по памяти? Речь о локальности данных?

IT>О декларативности работы с данными. Давай рассмотрим пример, может быть так понятней будет. Пример возьмём не очень сложный, но и не самый простой, т.к. на простых примерах вся мощь линка не так проявляется.


IT>Возьмём финансовую задачку. Допустим у нас есть провайдеры, которые тратят бабло и есть получатели, на которых это бабло списывается. С провайдеров деньги списываются через аккаунты в соответствии с определёнными процентами. Например, провайдер '1111' списывает 20% на аккаунт 'AAAA' и 80% на аккаунт 'BBBB'. Получатели получают свою долю тоже через аккаунты, по такому же принципу, т.е., например, получатель '8888' получает 40% с аккаунта 'AAAA' и 60% с аккаунта 'BBBB'. Наша задача получить массив процентов, в котором будет указано, что провайдер '1111' списывает через аккаунт 'AAAA' столько-то процентов на '8888'.


IT>Ниже приведён код. Метод CalcPercents делает эту работу с помощью linq, метод CalcPercents2 в исполнении C# 2.0.


IT>Обрати внимание, кода на линке в 3 раза меньше и он декларативен, в отличии от императивщины на C# 2.0. А если учесть, что таких вычислений у меня в коде пачками, то выгода linq более чем очевидна.

Мда... Сильно! Ладно, Linq-to-Objects оправдан Пока...

MK>>Но вообще, IT, я бы хотел еще раз обозначить, что я принципе не против Linq. Хотелось бы просто понимать реальную необходимость этого, реальные плюсы, а не просто как "игрушка для этюдов". Разве это есть гуд, требовать "что", не понимая "как"?


IT>Но ты же не говоришь SQL серверу как именно выполнять запросы? Ты говоришь, хочу то-то и то-то, а он уже сам читает с диска или из кеша, оптимизирует запросы и занимается прочими 'как'.

Не совсем, тюнем же план запроса. Если в точности говорить "как", пришлось бы очень много кода писать и боюсь смысла в СУБД тогда было бы совсем мало.
Re[21]: Давайте поговорим о c# 3.0
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.09.08 09:01
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Являются частью стандарта.


Только в части, касаемой DDL, что, очевидно, за рамками linq.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[26]: Давайте поговорим о c# 3.0
От: Lloyd Россия  
Дата: 23.09.08 10:30
Оценка:
Здравствуйте, Sinclair, Вы писали:

L>>Предположим, что у нас есть класс "Группа", у которой есть свойство-коллекция "Студенты".

L>>Что должно произойти с содержимым этой поллекции при удалении студента не напрямую, а опосредованно, через delete-запрос?
S>А с чего что-то должно происходить с классами при удалении объектов?
S>Если тебя интересует, что произойдет с экземплярами этих классов, то ответ — ничего.

Прочти внимательнее.

S>Потому, что эти экземпляры были подняты в память в рамках некоторого запроса; и они актуальны на момент выполнения этого запроса.


S>Тебя же не беспокоит, что DataTable, зачитанный десять минут назад, не обновляется автомагически оттого, что где-то еще (может быть в другом потоке, в другой транзакции, да и вообще в другом приложении) была выполнена модифицирующая операция? А почему тебя беспокоят студенты и группы?


Я не понимаю твоей логики. У нас есть два решения: в одном есть проблема A, в другом проблемы A и B. Очевидно, что второе решение хуже. А с твоих слов получается, что разницы никакой, т.к. оба решения имеют проблему A. Так что ли?
P.S. Проблема A — рассогласование данных между 2-мя разными DataContext-ами. Проблема A — рассогласование данных между внутри одного DataContext-а.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[7]: Давайте поговорим о c# 3.0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 23.09.08 10:40
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>А если я хочу сказать: «Некто Тр___сен заявляет, будто неплохо разбирается в .NET»?


В этом случае я бы ориентировался на то, какую книгу я собираюсь процитировать в подтверждение своих слов.
Re[12]: Давайте поговорим о c# 3.0
От: IT Россия linq2db.com
Дата: 23.09.08 13:45
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Гм... какая-то безграничная любовь у многих вас к Немерле. Не сотвори себе кумира


Любовь, это да, но дело не в кумирстве. Немерле можно сравнить с оружием джидаев по сравнению с сегодняшними пукалками, которыми вооружен мэйнстрим

IT>>По мне, так EF — это чистый маркетинг. Наш ответ Хайберлену. Есть же в конце концов и другие невостребованные технологии у MS вроде того же WWF. Будет ещё одна.

MK>Я её еще не пробовал, только статейки посмотрел. Она в чем-то схожа с фреймворком фирмы, о которой уже писал. У них давно решено и то, что в Linq-to-Sql зовется identity и типизация строгая (но генераторами, да) и простые скрипты можно формировать в терминах бизнес-объектов, но не имея самих объектов в памяти. Это я к тому, что возможно Linq-to-Sql меня не столь радует из-за более раннего знакомства с, на мой взгляд, более сильной технологией. Надеюсь в будущих версиях, Майкрософт всё же улучшит Sql'ную составляющую Линка, допустив при желании его использование именно как генератора.

Ну понятно. Что-то типа очередного ORM, заточенного под конкретную задачу. Вполне возможно. Мы что-то подобное делали ещё в 2003-м году в IBM, но диапазон задач был таков, что уже под следущую пришлось бы клепать что-то подобное, но своё. Хотя, если потратить на это несколько лет, то наверное можно вылепить ещё один Hibernate.

IT>>Но ты же не говоришь SQL серверу как именно выполнять запросы? Ты говоришь, хочу то-то и то-то, а он уже сам читает с диска или из кеша, оптимизирует запросы и занимается прочими 'как'.

MK>Не совсем, тюнем же план запроса. Если в точности говорить "как", пришлось бы очень много кода писать и боюсь смысла в СУБД тогда было бы совсем мало.

Ну ты понял
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Давайте поговорим о c# 3.0
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 24.09.08 02:55
Оценка:
Здравствуйте, Lloyd, Вы писали:
L>Я не понимаю твоей логики. У нас есть два решения: в одном есть проблема A, в другом проблемы A и B. Очевидно, что второе решение хуже. А с твоих слов получается, что разницы никакой, т.к. оба решения имеют проблему A. Так что ли?
L>P.S. Проблема A — рассогласование данных между 2-мя разными DataContext-ами. Проблема A — рассогласование данных между внутри одного DataContext-а.

Так, я понял, в чем дело. Ты подразумеваешь под контекстом DataContext, т.е. кэш с identity tracking. А я подразумеваю контекст транзакции, а identity tracking считаю вредной придумкой. Вообще идея "давайте поднимем объекты в память, там их поредактируем, и опустим обратно" мне не очень нравится. Она плохо отражает реальные события. С ее помощью невозможно сделать традиционные для RDBMS вещи типа элементарного update account set balance = balance + @amount.

Я понимаю, зачем она была сделана, но я бы, наверное, предпочел еще более lightweight реализацию, которая по честному является тонкой оболочкой над SQL. Зато с поддержкой всех четырех стейтментов.
И я, кстати, подозреваю, что это таки возможно в рамках ЗАИЯ.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[28]: Давайте поговорим о c# 3.0
От: Lloyd Россия  
Дата: 24.09.08 03:26
Оценка:
Здравствуйте, Sinclair, Вы писали:

L>>Я не понимаю твоей логики. У нас есть два решения: в одном есть проблема A, в другом проблемы A и B. Очевидно, что второе решение хуже. А с твоих слов получается, что разницы никакой, т.к. оба решения имеют проблему A. Так что ли?

L>>P.S. Проблема A — рассогласование данных между 2-мя разными DataContext-ами. Проблема A — рассогласование данных между внутри одного DataContext-а.

S>Так, я понял, в чем дело. Ты подразумеваешь под контекстом DataContext, т.е. кэш с identity tracking. А я подразумеваю контекст транзакции, а identity tracking считаю вредной придумкой. Вообще идея "давайте поднимем объекты в память, там их поредактируем, и опустим обратно" мне не очень нравится. Она плохо отражает реальные события. С ее помощью невозможно сделать традиционные для RDBMS вещи типа элементарного update account set balance = balance + @amount.


Это всего лишь говорит о том, что при работе через DataContext, не нужно работать в обход него. Проблемы будут неминуемы. А поэтому и нет необходимости delete по expression-у в DataContext-е.

S>Я понимаю, зачем она была сделана, но я бы, наверное, предпочел еще более lightweight реализацию, которая по честному является тонкой оболочкой над SQL. Зато с поддержкой всех четырех стейтментов.

S>И я, кстати, подозреваю, что это таки возможно в рамках ЗАИЯ.

ЗАИЯ
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[3]: Давайте поговорим о c# 3.0
От: Трофимов  
Дата: 24.09.08 04:59
Оценка: :)
RO>Во-первых, не издевайтесь над Трёльсеном (не знаю, хорошо ли он пишет, но всё равно нечего перевирать имя).
Расслабься, после Бьёрна Страустрапа нам уже ничего не страшно.

RO>Во-вторых, все известные мне языки, которые пытались устранить низкоуровневые «сложности» и объединить сущности «объект» и «адрес объекта», наступили на одни и те же грабли и связывают объекты вместо копирования или наоборот неочевидным для программиста образом. Чем больше будет распространен C#, тем больше анонимов будут задавать одни и те же вопросы на соответствующих форумах. Да что далеко ходить: самое верхнее сообщение на rsdn.dotnet под модным номером 3110110
Автор:
Дата: 19.09.08
: «А теперь вопрос — почему при удалении строк из dt также удаляются строки из ViewState? Догадываюсь, что копируется ссылка, а как правильно скопировать, чтобы создалась копия объекта?». Тем более, что грабли замедленного действия: программа компилируется и работает, но тихо редактирует не те данные.


Ага, а C++-ное копирование никаких граблей не подбрасывает, и анонимы всегда редактируют именно те данные, которые надо. Ага. Интересно, а анонимов не смущает, что когда они редактируют вьюху SELECT * FROM tbl1 WHERE col1=0, при этом предательским образом изменяются данные в tbl1?

RO>В-третьих, пока C# привязан к одной определенной платформе, он годится только на то, чтобы флудить о нем в ФП, а на сервер пойдут решения, которые при нужде можно будет перенести куда понадобится


Гм, речь идёт о каком-то одном сервере или о серверах вообще?
Re[29]: Давайте поговорим о c# 3.0
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 24.09.08 05:11
Оценка: 1 (1) +2
Здравствуйте, Lloyd, Вы писали:

L>Это всего лишь говорит о том, что при работе через DataContext, не нужно работать в обход него. Проблемы будут неминуемы.

Это всего лишь говорит о том, что identity tracking несовместим с 75% DML. Тут я совершенно согласен — нужно выбирать что-то одно: либо identity tracking либо 75% DML.
L>А поэтому и нет необходимости delete по expression-у в DataContext-е.
Логика на высоте. "Новая помада не подошла к цвету машины, поэтому я пошла пешком".

Я всё еще не вижу причин, по которой ты считаешь identity tracking заметно лучше, чем прямое отображение insert/update/delete в SQL.

Судя по переписке в другой ветке, твоя ментальная модель работы с данными именно такая: "загрузить-изменить-записать". Причем последнюю часть пусть думает DataAdapter, у него работа такая. Это радикально отличается от идеологии SQL; датаадаптер в датасетах и идентити трэкинг в линке пытаются натянуть идеологию "работы через курсор", привычную по Delphi, Access, FoxPro и прочим технологиям восьмидесятых, на запрос-ориентированную клиент-серверную технологию SQL.

Вся идея SQL — в том, что нет такой операции "поредактировать результат запроса". Есть update table. Это совсем не то же самое.
Как я могу поапдейтить результат запроса select student, avg(mark) from ... group by student?
В update table я прямо указываю, какие колонки я хочу поредактировать, и зачем.
Датаадаптер пытается вычислить за меня последовательность действий, которые я имел в виду. Иногда ему это удается. Но принципиальная проблема как раз в том, что выразительность семантики "сохранить объект" недостаточна. Вот было бы наоборот — было бы хорошо. Точно так же как сам update в sql не требует указывать подробности на уровне файлов, любая механика поверх SQL должна по идее нас изолировать от несущественных подробностей. Увы, пока что все эти припрыгивания изолируют нас от существенных подробностей.

L>ЗАИЯ

ЗАпросы Интегрированные в Язык = Language-INtegrated Query
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[13]: Давайте поговорим о c# 3.0
От: VoidEx  
Дата: 24.09.08 11:37
Оценка:
Здравствуйте, IT, Вы писали:

IT>Любовь, это да, но дело не в кумирстве. Немерле можно сравнить с оружием джидаев по сравнению с сегодняшними пукалками, которыми вооружен мэйнстрим


Оружие Джедаев — это такая светящаяся палка, которая на раз сносится мейнстримовой ядерной бомбой вместе с самими Джедаями?
Re[12]: Давайте поговорим о c# 3.0
От: Mirrorer  
Дата: 24.09.08 11:43
Оценка: 10 (3) +2
Здравствуйте, MxKazan, Вы писали:

MK>Вопрос то не в этом. Пока что большинство аргументов "за" выглядят примерно так: "появилась новая фича, значит она точно необходима и ей нужно пользоваться".

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

Ну например. Возьмем простой пример. Просуммировать список чисел
var someList = new int {1,2,3,4,5};

var sum = 0;

foreach var x in someList
   sum += x


Идея какая такой операции. Пробежать по всем элементам списка и сложить все в сумму.
То бишь аккумулировать результат.

Допустим нам понадобилось сделать умножение.
Проще простого
var sum = 1;
foreach var x in someList
   sum *= x


И что видно ? Видно дублирование кода. Отличие только в начальном значении суммы и функции, которая будет применяться на каждом шаге.
Хорошо было бы иметь возможность указывать только эту информацию, без того, чтобы каждый раз писать foreach

Итак пишем функцию
        public A Accumulate<A,I>(A accum, Func<A, I, A> fun, List<I> list)
        {
            foreach (var x in list)
            {
                accum = fun(x, accum);
            }
            return accum;
        }
// а вот так используем
  var sum2 = Accumulate<int, int>(0, (s, x) => s + x);


Мы теперь можно чувствовать себя крутым. Мы абсрагировали способ обхода коллекции (foreach) от операций которые будут выполняться на каждом шаге. Уберутся ненужные дублирования и т.п.

Но это ощущение быстро рассеивается поскольку в C# 3.0 наша доморощенная Accumulate уже есть
var  sum = l.Aggregate(0, (s, x) => s + x);


А в f#
оно вообще будет выглядеть как
let sum = foldl (+) 0 someList


И все эти функции появившиеся в третьем шарпе злостные баяны в ФП мире, которые по чуть-чуть перетягиваются в мейнстрим. И для того, чтобы понять какие возможности они открывают, надо глядеть на функциональные языки.
Такие дела.
Re[14]: Давайте поговорим о c# 3.0
От: WolfHound  
Дата: 24.09.08 12:05
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Оружие Джедаев — это такая светящаяся палка, которая на раз сносится мейнстримовой ядерной бомбой вместе с самими Джедаями?

Джедай это такой навороченный спецназ... И современное ополчение с пукалками он зарулит на раз.
А против ядерной бомбы звезда смерти есть...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: Давайте поговорим о c# 3.0
От: Lloyd Россия  
Дата: 24.09.08 12:44
Оценка:
Здравствуйте, Sinclair, Вы писали:

L>>А поэтому и нет необходимости delete по expression-у в DataContext-е.

S> Логика на высоте. "Новая помада не подошла к цвету машины, поэтому я пошла пешком".

S>Я всё еще не вижу причин, по которой ты считаешь identity tracking заметно лучше, чем прямое отображение insert/update/delete в SQL.


я так не считаю, я считаю что DataContext (c identity tracking) лучше чем DataContext(Sinclair edition) (c identity tracking и delete-ами через expression в обном флаконе).
Так надеюсь понятнее?

S>Судя по переписке в другой ветке, твоя ментальная модель работы с данными именно такая: "загрузить-изменить-записать". Причем последнюю часть пусть думает DataAdapter, у него работа такая. Это радикально отличается от идеологии SQL; датаадаптер в датасетах и идентити трэкинг в линке пытаются натянуть идеологию "работы через курсор", привычную по Delphi, Access, FoxPro и прочим технологиям восьмидесятых, на запрос-ориентированную клиент-серверную технологию SQL.


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

S>Вся идея SQL — в том, что нет такой операции "поредактировать результат запроса". Есть update table. Это совсем не то же самое.

S>Как я могу поапдейтить результат запроса select student, avg(mark) from ... group by student?

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

S>В update table я прямо указываю, какие колонки я хочу поредактировать, и зачем.

S>Датаадаптер пытается вычислить за меня последовательность действий, которые я имел в виду. Иногда ему это удается. Но принципиальная проблема как раз в том, что выразительность семантики "сохранить объект" недостаточна.

Мне пока хватает. И за десять лет мне как-то не доводилось сталкиваться с проектами, где это действительно было надо. Может быть за исключением только случаев, когда были массовые операции, в этих случаях применение plain sql-я было вполне оправдано. Но такого рода задачи, к счастью не так часть встречаются.

S>Вот было бы наоборот — было бы хорошо. Точно так же как сам update в sql не требует указывать подробности на уровне файлов, любая механика поверх SQL должна по идее нас изолировать от несущественных подробностей. Увы, пока что все эти припрыгивания изолируют нас от существенных подробностей.


В ничтожно малом кол-ве сценариев.

P.S. На досуге рекомендую подумать в каких сценариям DataContext может даже и способствовать перформансу. Подсказка: погугли по "unit of work".
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[13]: Давайте поговорим о c# 3.0
От: MxKazan Россия  
Дата: 24.09.08 13:21
Оценка:
Здравствуйте, Mirrorer, Вы писали:

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


MK>>Вопрос то не в этом. Пока что большинство аргументов "за" выглядят примерно так: "появилась новая фича, значит она точно необходима и ей нужно пользоваться".

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

M>Ну например. Возьмем простой пример. Просуммировать список чисел


M>Идея какая такой операции. Пробежать по всем элементам списка и сложить все в сумму.

M>То бишь аккумулировать результат.

M>И что видно ? Видно дублирование кода. Отличие только в начальном значении суммы и функции, которая будет применяться на каждом шаге.

M>Хорошо было бы иметь возможность указывать только эту информацию, без того, чтобы каждый раз писать foreach

M>И все эти функции появившиеся в третьем шарпе злостные баяны в ФП мире, которые по чуть-чуть перетягиваются в мейнстрим. И для того, чтобы понять какие возможности они открывают, надо глядеть на функциональные языки.

M>Такие дела.

Спасибо, Mirrorer. Вот пример так пример про суммирование и сложение элементов — простой и понятный, очень понравилось.
Только всё же выскажу, что эти var'ы прямо глаза коробят, того и гляди о типизации думать перестанем

P.S. Гы. И здесь это любимое на всяких музыкальных тру-форумах слово "мейнстрим"
Re[31]: Давайте поговорим о c# 3.0
От: MxKazan Россия  
Дата: 24.09.08 13:30
Оценка: +1
Здравствуйте, Lloyd, Вы писали:

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


L>>>А поэтому и нет необходимости delete по expression-у в DataContext-е.

S>> Логика на высоте. "Новая помада не подошла к цвету машины, поэтому я пошла пешком".

S>>Я всё еще не вижу причин, по которой ты считаешь identity tracking заметно лучше, чем прямое отображение insert/update/delete в SQL.


L>я так не считаю, я считаю что DataContext (c identity tracking) лучше чем DataContext(Sinclair edition) (c identity tracking и delete-ами через expression в обном флаконе).

L>Так надеюсь понятнее?

Lloyd, по-моему, Sinclair имеет ввиду, что ему не нужно identity tracking, если оно мешает выполнять типовые запросы БД. Получилась концепция частично ради самой себя — пользоваться можно, но то здесь, то там приходиться извращаться для решения типовых задач.
Re[14]: Давайте поговорим о c# 3.0
От: Mirrorer  
Дата: 24.09.08 13:36
Оценка: +1
Здравствуйте, MxKazan, Вы писали:

MK>Только всё же выскажу, что эти var'ы прямо глаза коробят, того и гляди о типизации думать перестанем

В пределах метода оно не страшно. Особенно если методы не на 10 экранов. Все понятно из контекста.
Тем более что типизация никуда не девается. В Haskell-e допустим можно вообще ни один тип не указывать, все компилятор выведет. Но от этого язык менее строгим не становится.

MK>P.S. Гы. И здесь это любимое на всяких музыкальных тру-форумах слово "мейнстрим"

Ну а как иначе. Большинство идей, которые попадают в языки, были описаны в академических исследованиях 19.. лохматого года. А потом по чуть-чуть из башен слоновой кости идеи перетекают в индустрию в пережеванном и удобном для употребления виде.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.