Change Set 21282 - Lazy Loads, Transactions, and Changing Connection Strings on the Fly

April 17, 2007 18:21

First off, let me say huge thanks to Brenton Webster who provide the virtually all of the code responsible for the transaction enhancements in the set. Had it not been for Brenton, I might never experience the utter coolness of [ThreadStatic].

So there's some new stuff here. First, since I really don't feel like having the debate about Properties vs. Methods and Lazy Loading again, I've added support for both. Using the boolean parameters generateLazyLoads and generateRelatedTablesAsProperties on the provider, you can determine the output of the related table methods. Personally, I'm happy with methods and chose them because it the approach taken by datasets, and could care less about lazy loading since I always assign the results of external call to local variables, but I've already spent more time debating this than it took to add the capability, so hopefully this will be at least close to the final word on it.

Next up, the SqlDataProvider (other providers at a later date) now supports runtime connection string switching. Big thanks again to Brenton on this one, since the code he provided for the transaction handling made adding this capability very simple. There are really only two command you need to know to use it. To change the connection string currently being used by the provider, use:

SqlConnectionContext.Create("your connection string here");

and to return it to the provider default, use:

SqlConnectionContext.Reset();

That's all there is to it.

Finally, there are the transaction enhancements I spoke of earlier. As Brenton noted there two issues with relying on System.Transactions for transaction performance: Performance, and. I've incorporated his very elegant solution, so you can now use transactions (again SqlDataProvider only for now) without the mentioned limitations. At the most base level, the syntax is as follows:

using (TransactionScope scope = new TransactionScope())
{
     //Do stuff
     ....
     scope.Complete();
}

 

So beat these up and find the stuff that I screwed up, so that we can move on to Beta 4.

Fixes

  • Work Item 9648 - SubSonicCentral web.config - invalid path to templateDirectory breaks Configuration Builder page
  • Work Item 9516 - SubSonic and System.Transaction support
  • Work Item 9691 - Dropdown control needs orderField
  • Work Item 9656 - Generated ActiveRecord "primary key methods" --> properties
  • Work Item 9270 - SqlDataProvider - single method for creation of new connection

Download


10 Comments
Actions: E-mail | Permalink | Comment RSSRSS comment feed

Related posts

Comments

April 17. 2007 18:44

Gavin Joyce

Thanks for adding support for lazy-loaded properties. I'll keep quite now, I promise Smile.

Gavin Joyce

April 17. 2007 19:06

kevin

good deal. great stuff! the lazy-loading debate was interesting. the property vs method debate was a little too much.

rock on!

kevin

April 17. 2007 20:32

Geri Langlois

I can't thank you enough for adding code that allows changing connection strings on the fly. Wow, this will make my life so much easier!

Geri Langlois

April 17. 2007 23:00

Justin M. Keyes

The SqlConnectionScope() ctor check (SqlConnectionContext.Current != null), however, I don't understand how that condition could ever be true. Is the end-user still supposed to call SqlConnectionContext.Create(), as Brenton showed in work item 9516?

Justin M. Keyes

April 18. 2007 00:48

Eric Kemp

SqlConnectionContext.Create() should be called only if you are using a connection string other than the default one in the provider. If you are never switching connection strings, you never need to call SqlConnectionContext.Create().

SqlConnectionContext.Current will be null if SqlConnectionContext.Reset() has been called prior, forcing SqlConnectionContext to use the provider connection string that is passed.

Eric Kemp

April 18. 2007 01:16

kevin

Eric,

I'm getting this (below) now when executing Batch Class generator.

With the previous version - no error (and no schema changes have been made).

I'll post in issue tracker.

Error: Error generating template code: this happens because the rendering code (not that of the template) has encountered an error. Most likely it has to do with a Primary Key - make sure one is defined for this table. Other possibilities revolve around reserved words and naming... Here's some more detail: Compile Error: No overload for method 'GetSchema' takes '2' arguments Compile Error: No overload for method 'GetSchema' takes '2' arguments Compile Error: No overload for method 'GetSchema' takes '2' arguments

kevin

April 18. 2007 01:38

Eric Kemp

Are you sure you're using the same Change Set versions of ClassGenerator.ascx.cs and DataService.cs?

The 21282 Change Set should have a method in DataService with the following signature:

public static TableSchema.Table GetTableSchema(string tableName, string providerName)

Eric Kemp

April 18. 2007 01:58

Eric Kemp

I think there a couple templates that didn't get modified for signature changes in the DataService.GetSchema.

Until my next check in, you should just be able to uncomment the GetSchema method that's at line 382 in DataService.

Eric Kemp

April 18. 2007 15:19

Justin M. Keyes

Ok, I understand it better now, but I'm still confused. The only place I see a provider connection string being passed is in the SqlConnectionScope() constructor--but SqlConnectionContext._connection (the [ThreadStatic] connection) isn't assigned from anywhere except SqlConnectionContext.Create()--and, as far as I can tell, SqlConnectionContext.Create() isn't being called from anywhere.

Justin M. Keyes

April 18. 2007 17:56

Eric Kemp

I'm going to be posting a new version shortly with a revised implementation based on conversations with Brenton, which should clarify and correct some stuff. Should be up in a few hours.

Eric Kemp

Comments are closed