Monday, September 17, 2007

Column defaults in LINQ to SQL

There's some weird behavior in LINQ to SQL Beta2 around column defaults. It seems that you have to make a choice between using a column default or having an editable value- you can't have both. For instance- a number of our tables have a CreateDate field with a column default of GETUTCDATE(). The default O/R designer behavior for this is to set IsDBGenerated = true, and ReadOnly = true. This results in a read-only property that uses the column default value of the current date/time when we insert a new row. Most of our inserts don't supply a value for CreateDate, so we get the current date/time, which is usually what we want. However, sometimes we're using the same DBML definition to migrate old data (where we'd specify a CreateDate in the past). This is where it gets problematic. The designer lets me flip that ReadOnly bit to false, and will generate a setter for CreateDate. Unfortunately, it's not usable- any value I set is ignored. Seems like it'd work fine for generated types where full change tracking is available- "not set" is distinguishable from "set to null" or "set to a value". I'm hoping this one's fixed for RTM- I've been too busy to file the bug on it.

No comments: