One of the features added in SubSonic 2.0 was a new mechanism for setting default values on the properties of newly initialized ActiveRecord objects. While SubSonic has long had a mechanism for setting default values based on the particular data type of a column/property, version 2.0 introduced a new mechanism which retrieved default values by perform a SQL SELECT on the default value of column, which made it possible to initialize these properties with values that were as close as possible to those set by the database.

In many situations this works out quite well. For example, by using getdate() value returned by SQL for a DateTime property rather DataTime.Now you can address time zone or synchronization differences between the web server and the database. In addition, it allows for more flexible control of default values, as they are set in the database columns rather than in the SubSonic library.

Unfortunately, this functionality comes at a price. The first one we discovered was that one of the new SQL 2005 functions, newsequentialid(), cannot be invoked with a straight SELECT statement. While we were able to create a condition for this particular expression, we soon discovered that there were other possible problem conditions, such as one that Rick Strahl help us to identify, where the a default value of 0 was expressed (validly) as UW_ZeroDefault.

The bigger potential issue is the overall "chattiness" of the approach. The magnitude of the issue can vary significantly based on the specifics of your application and how often you set default values on database columns. However the problem is exponentially exacerbated by a current limitation of our ActiveRecord objects.

Currently, there is no [clean] way for us to distinguish between new objects that are being created as part of database fetch, versus those that are new instances to be inserted upon Save(). This means that fetched objects go through the same initialization process as new ones, resulting in unnecessary database calls. But the worst part is that this is not just an issue for single record retrievals, but also for every single record loaded into a collection. Ugh!

This issue will be address in future modifications to the architecture, but right now is not the time, when we're trying to get 2.0.2 out the door. So all this a long way of introducing a change in the way defaults are set on objects. As of Revision 100, the de facto behavior of SubSonic is to not set defaults from the database. Values will instead be initialized by the mechanism used prior to 2.0, where a standard value is assigned based on data type.

However, if you can tolerate the overhead, you can re-enable the setting of default from the database via the following provider configuration property.

setPropertyDefaultsFromDatabase="true"

Thanks for reading, and please share your thoughts...