Behavior Change in SetDefaults()

June 13, 2007 17:48

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... 


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

Related posts

Comments

June 13. 2007 18:41

James

Ha, only this week I removed loads of defaults from my database in order to stop this chattiness. Guess I'll be able to put them back in again now.

James

June 14. 2007 06:54

Maciej

Great!
Thank you very much.

PS. When we can expect new binaries of Subsonic? Smile

Maciej

June 14. 2007 18:11

phill_jones

This is a wise move I think - chattiness - as my wife often reminds me - is a bad thing.

Thanks for all your efforts.

phill_jones

June 15. 2007 16:21

jpantuso

There may be some useful middle ground where when the base classes are constructed based on the table (compile time), or first initialized (run time), any defaults that can be managed through code are taken into account.

For example I have lots of defaults that are booleans or fixed numeric values. Things of that nature would not require a round-trip to the database for each object.

jpantuso

June 15. 2007 16:53

Eric Kemp

The problem with going that route is that we have to anticipate all the different possible way these defaults could appear and parse them, which can be slippery slope. However, if can find a clean way to apply the 80/20 rule, these will probably be phased in over time.

Since this was posted, there a new ActiveRecord overload has been added, which allows on a per instance basis, whether or not to go to the database for values. This might help the situation a bit...

Eric Kemp

June 18. 2007 10:01

Andrew Rimmer

Excellent, this should be a good boost on performance.

Do you have a rough idea when the next stable version of SubSonic will be released?

Andrew Rimmer

June 18. 2007 13:24

Eric Kemp

Well, we had said last week, but that clearly didn't happen. Smile

For the most part, everything that we intended for this release is in there now, so it's mostly a matter of inventorying the changes and packaging it up.

We're looking in good shape for a release this week (seriously).

Eric Kemp

Comments are closed