Re: LINQ for SQL Conflict Resolution

> On Mon, 6 Apr 2009 17:07:23 +0200, 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.
> 
> Yep, that's exactly it. The auditing stuff requires some data that only
> becomes available when the delete happens. If we simply deleted the
record,
> then there would be no means for an AFTER DELETE trigger to access that
> data. OTOH an AFTER UPDATE trigger can get to that data because it has
> access to the value of the record after the update happened.

	I think you mean data which is deleted as well from other tables
through cascades? Otherwise I don't see which data you're referring to. 

> However, it looks like in the absence of any other convenient solutions
> we're going to 'solve' the problem by abandoning the trigger and moving
the
> auditing logic back to the business layer - so the business layer uses
LINQ
> for SQL to delete the object in the DB and then separately use LINQ for
SQL
> to write the auditing records to the DB.

	Here's how we implemented Auditing support in llblgen pro: through
dependency injection an Auditor is injected into entities (you could do this
too with a DI framework like structuremap in linq to sql), and all
changes/actions on the entity are recorded by the auditor, it simply gets a
call that something was changed (if it's there of course) and it records it.

	
	When persistence occurs, it gets a call if it has anything to add to
the existing transaction. If so, it could return new entities to store, or
do whatever it wants (like write to a logfile, it's up to you, it's your
code). This is completely transparent to the developer, as the auditor is a
separate class and injected through DI, it's configurating the thing and go.


	So what you could do is in linq to sql use the tap-in methods
(partial methods) to call into an injected auditor, if there, and record
changes, perhaps also do this on the context, though I think that's a bit
cumbersome. then when the context persists entities, you could bind to the
event it raises when doing that and look at the data the auditors have
recorded and store that too. 

	I'm not sure if linq to sql offers this complete route, the key is
that you can record changes/actions and get a signal from the context that
the entity object life's is over and you have to persist the recorded info.
It's also key that this is done inside the same transaction, which might be
difficult to do in linq to sql. 

		FB

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