views:

34

answers:

2

Hi Guys

I wrote a an application for configuring a platform we have. Our current process is make the configuration changes in a staging environment and when they're approved, make the same changes in a production environment.

There's room for error in this process in that there's a risk that the user might mistakenly make a change in production that wasn't approved in staging. It would be easy to click the wrong button or select the wrong choice from a list if the user isn't careful.

I've been thinking that this risk would be mitigated if we could save all the LINQ-to-SQL operations that put the staging environment into its current approved state, and re-run those saved operations in the production environment, instead of making the same changes manually.

I suppose what I'm trying to ask is if there's any way to 'script out' the Inserts/Updates/Deletes that my LINQ-to-SQL performs?

Is this a realistic idea? If not, could somebody suggest a different approach to this issue?

Thanks

Dave

+1  A: 

You set the Log property on the DataContext to see the rendered SQL. A quick search brings up this interesting page:

http://www.u2u.info/Blogs/Kris/Lists/Posts/Post.aspx?ID=11

spender
+1  A: 

Given your real problem (i.e. propagating configuration changes from staging to production) I think that a better solution would be to develop a mechanism of taking/applying 'configuration snapshots' rather than logging and applying actions that produced the configuration you need.

You solution (logging queries from data context) has the following disadvantages that lay on the surface:

  • it depends on initial state of configuration (you're going to run into problems in case your production configuration differs from staging configuration when you start logging your actions)
  • you're dealing with a list of actions (which can be quite complex) while you're actually interested in a result of those actions - so it's better to save final result
AlexS
@AlexS: Your suggestion of "taking/applying 'configuration snapshots'" would be ideal for what I am trying to achieve. The issue with that is the production database has some replecation utility running which prevents us from overwriting it with a new snapshot. Replecation _could_ be switched off to apply the snapshot, but that requires the involvement of SysAdmin which is a lot of overhead.
DaveDev