Ah... the first day of spring! A time for renewal and rejuvenation, and an appropriate change set to accompany it. This build contains some core changes that I've been been as eager to see addressed in SubSonic as I am glad to see this cold New England winter officially over. We can't all live in Hawaii...

Enough about that... This Change Set contains a new piece of functionality: Regular Expression support! Via three parameters on the provider, you can now use Regular Expression to transform the naming of Tables, Views, Properties, and Stored Procedures without impacting the underlying data access or database naming. The configuration parameters are:

• regexMatchExpression (string)
• regexReplaceExpression (string)
• regexIgnoreCase (bool, default is false)

The setting of these values are pumped through the following method at code generation time:

public static string RegexTransform(string inputText, string matchString, string replaceString, bool caseSensitive)
{
     Regex rx;
     if(caseSensitive)
     {
          rx = new Regex(matchString);
     }
     else      
     {
	  rx = new Regex(matchString, RegexOptions.IgnoreCase);
     }
     return rx.Replace(inputText, replaceString);
}

The more you know about Regular Expressions, the more you'll be able to do with this. However, even if you're not familiar with them, you can still use the settings to do simple replaces. For example, try the following provider against the Northwind database, and you'll see all references to "Product" become "Widget":

<add name="Northwind" type="SubSonic.SqlDataProvider, SubSonic" connectionStringName="Northwind" 
generatedNamespace="Northwind" regexMatchExpression="Product" regexReplaceExpression="Widget"/>

In constructing this capability, the majority of the convention based naming was pushed down into the schema level. This was a painful change that hit hundreds of references, but one which should significantly simplify naming issues going forward. In addition, as of this build, the providers configurations are truly independent, and there is no longer the potential for settings from one provider to "leak" into another.

I would consider this a high-risk build, but for those who are brave I welcome your feedback.

Please note: You will need to regenerate any existing classes when upgrading to this build!

Download