Привет.

Подскажите, пожалуйста, как можно обновить LINQ класс как объект.. Звучит глупо, но:



Это сообщение отредактировал(а) KLUBS - 21.12.2008, 01:09

Чем больше поллей в таблице, тем больше полей нужно обновлять руками, если изменяешь структуру таблицы.. то все летит..

KLUBS, 

http://blogs.msdn.com/dinesh.kulkarni/arch...g-detached.aspx
если нужен concurrency, то просто вызова Attach(customer, cust) должно хватить.

Это сообщение отредактировал(а) PashaPash - 21.12.2008, 16:58

В том то и дело, что не получается. 
этот метод вызывает исключение: 

An attempt has been made to Attach or Add an entity that is not new, perhaps having been loaded from another DataContext

Вроде решил, сделал DataContext - статическим для всего класса, и теперь, при обновлении просто пишу dataContext.SubmitChanges();

Так нормально?)

KLUBS, это плохое решание - практически, ты загружаешь в память полную копию базы.
Вообще проблема в том, что твой Customers ссылается на другие объекты, и для них срабатывает Deferred Loading - вмест объектов передаются незагруженные EntityRef. При попытке их сохранить все и падает. Решение - отключить DeferredLoading у оригинального контекста, тогда объект Customer будет существовать сам по себе.
Если не хочешь таскать с собой по коду originalCustomer - его можно выбирать прямо перед аттачем

Но лучше добавить в таблицу Customers поле c типом timestamp, можно будет делать прямо так:

PashaPash, 
первые 2 понятно.
Дело в том, что я делаю выборку из бд, пихаю ее в ListBox.DataContext потом, пользователь нажимает кнопку изменить, открывается окошко и в это окошко DataContext присваивается элемент этого ListBox'a (ListBox.SelectedValue as Customers). (+ ко всему все это на привязке данных)
Если я хочу изменить Весь объект Customers сразу, как мне быть?

1. обновить все поля вручную. Можно, но мне очень не нравится такой вариант, потому что при изменения чего то придется менять код этого места.

2. Attach(); вот тут то и начинается веселье. Он говорит, что не может обновить элемент, т.к. он получен из другого DataContext'a... еще часик покопавшись в нете, нашел вот этот метод решения этой задачи:

Я ж специально написал - отключить DeferredLoading у оригинального контекста, тогда объект Customer будет существовать сам по себе. В первом примере. context.DeferredLoadingEnabled = false;, может быть еще ObjectTrackingEnabled = false.
Я же проверил код, перед тем как постить - он точно не падает, и все вполне сохраняется без рефлекшена и прочих хаков.

а помимо DeferredLoadingEnabled = false и повторной выборки из контекста в котором будет вызван SubmitChanges() есть способы изменить объект не из этого контекста? ведь это же не рационально имея объект еще раз нагружать сервер, плюс трафик, по моему мелкософт схалтурил 

DeferredLoadingEnabled - это отложенная загрузка полей-ссылок. Чтобы она работала, объект должен быть привязан к датаконтексту. Для того, чтобы объект существовал сам по себе, его нужно явно оторвать он начального контекста (варианты с Detach, много в гугле), или просто не привязывать с самого начала (=false).
Без повторной выборки - смотри 3-й вариант, там без повторной выборки. "Нерациональная загрузка" обычно называется Optimistic Concurrency, и ей можно вполне нормально управлять, или вообще отключить, расставив UpdateCheck.None на колонках. Но для этого надо представлять последствия для конкретного приложения, и общий механизм работы change traсking-a, а не считать его халтурой microsoft. Авторы nHibernate и других нормальных ORM тоже подхалтуривают, судя по всему