Re: LINQ for SQL Conflict Resolution

Greg Young <[email protected]> Mon, 6 Apr 2009 11:24:28 -0400
Newsgroups gmane.comp.windows.devel.dotnet.advanced
Message-ID <[email protected]>
Maybe the pain here is good ... If its hurts to have a (no) bad
architecture people are more likely to have a better architecture.

Greg

On Mon, Apr 6, 2009 at 11:07 AM, Frans Bouma <[email protected]> wrote:
> I wonder why topic started hasn't consider an AFTER DELETE trigger instead
> for deletes? the code would become much simpler and still the deleted data
> is available for auditing purposes (in the trigger, similar to what it is
> now).
>
> Of course I'm not aware of what the auditing stuff contains so it might be
> more complex than that.
>
>> Yeah, not fun. If it's any help, you don't have to do it for all the CUD
>> operations, just the Delete, and let the runtime take care of the rest.
>>
>> I'm using LINQ to SQL in a Silverlight project, and I find myself
> basically
>> maintaining my client objects without it, only using LINQ 2 SQL in the WCF
>> Services to get the data. I also removed a lot of the FKs from the data
>> model because I was maintaining the client objects in my Silverlight app,
>> and with all the FKs the client objects became too bulky. I can get away
>> with this because the client classes are not very complex. A lot of the
>> classes generated by SQLMetal do not compile in Silverlight -- and on it
>> goes. Sigh. I briefly considered switching to the Entity Framework, but
>> decided to stick with LINQ 2 SQL because it has a smaller footprint on the
>> client side. I will probably reconsider down the road.
>
>        As silverlight is so stripped down, I don't think EF classes compile
> on silverlight either, you need DTO's and thus have to babysit the changes
> made and play them back on the server.
>
>        You could perhaps use some mechanism inside the DTO which tracks
> changes and which would make it easier to update the real entity on the
> server, but that would require a different code generator (as sqlmetal
> doesn't use templates).
>
>                FB
>
>>
>> Helen
>>
>> -----Original Message-----
>> From: Discussion of advanced .NET topics.
>> [mailto:[email protected]] On Behalf Of Simon Robinson
>> Sent: Monday, April 06, 2009 2:56 AM
>> To: [email protected]
>> Subject: Re: [ADVANCED-DOTNET] LINQ for SQL Conflict Resolution
>>
>> :-)  It may well come to that for me too. I was hoping to avoid having to
> do
>> that because it'd be a fair bit of work, harder to maintain going forward,
>> and would be a departure from how this particular DB is normally accessed.
>>
>> Simon
>>
>> On Wed, 1 Apr 2009 11:47:58 -0700, Helen Warn <[email protected]> wrote:
>>
>> >What I have done to avoid some of these pitfalls is to write my own
>> >stored procs for CUD operations, and then in the data model for the
>> >table, instead of using the default option of "Use Runtime" I customize
>> >the Insert,
>> Update,
>> >and Delete operations to use my stored procs. This adds them to the
>> >methods of the data context, so in code I use something like:
>> >
>> >    public int DeletePicture(Guid picture_uid)
>> >    {
>> >      using (MyDataContext context = new MyDataContext())
>> >      {
>> >        return context.delPicture(picture_uid);
>> >      }
>> >    }
>> >
>> >In the above, my stored proc returns an integer (actually @@rowcount).
>> >
>> >You may still not be out of the woods -- I found that I had to set some
>> >properties of FKs, etc. to cascade, but it got me around problems I had
>> when
>> >I just let the runtime handle CUD operations.
>> >
>> >Hope this helps,
>> >
>> >Helen
>> >
>> >-----Original Message-----
>> >From: Discussion of advanced .NET topics.
>> >[mailto:[email protected]] On Behalf Of Simon
>> >Robinson
>> >Sent: Wednesday, April 01, 2009 11:37 AM
>> >To: [email protected]
>> >Subject: [ADVANCED-DOTNET] LINQ for SQL Conflict Resolution
>> >
>> >I have a problem with a database update that is going through LINQ for
>> >SQL, via a call to DataContext.SubmitChanges().
>> >
>> >For reasons to do with auditing, we never delete records in this table
>> >directly; if we wish to delete a record, we do so by updating it to set
>> >an IS_DELETED bit field to 1. This is immediately picked up by an AFTER
>> >UPDATE trigger which does various auditing actions and then deletes the
>> record.
>> >
>> >The problem is this is throwing LINQ's concurrency processing: If I try
>> >to mark a record for deletion, the record isn't deleted, and
>> >SubmitChanges() throws the dreaded ChangeConflictException. The
>> >exception goes away if I comment out the line in the trigger that deletes
>> the row.
>> >
>> >Under the hood: It looks to me like SubmitChanges is sending two
>> >requests
>> to
>> >SQL server: An UPDATE to make the changes, immediately followed by a
>> >SELECT to verify that there are no concurrency issues. I think the
>> >trigger is getting in first, resulting in the SELECT returning no rows,
>> >hence the exception. For some reason this also seems to result in the
>> >delete getting rolled back, which is more serious (I'm not clear how
>> >that happens; it may indicate my analysis of what's going on under the
>> >hood isn't quite correct.).
>> >
>> >So in short - is there any easy way to tell DataContext.SubmitChanges()
>> >not to worry if the row it thinks it's updated disappears? Or any other
>> >solution?
>> >
>> >===================================
>> >View archives and manage your subscription(s) at
>> >http://peach.ease.lsoft.com/archives
>> >
>> >===================================
>> >View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>>
>> ===================================
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>>
>> ===================================
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>
> ===================================
> View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives
>



-- 
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives