On Sep 7, 2007, at 7:23 AM, John Siracusa wrote: > On 9/7/07 12:04 AM, Ask Bjørn Hansen wrote: >> On Sep 6, 2007, at 7:16 PM, John Siracusa wrote: >>> Or I suppose you could do the reverse, requiring a "special" >>> value to >>> trigger the use of a default and leaving undef as the null stand-in. >> >> That'd by far be my preference. In the application code undef and >> NULL maps so beautifully. Also it keeps use of the "special" value >> mostly inside RDBO. > > But what about all the existing code that expects undef to trigger > the use > of the default value? > > Hm, how about this: a new column attribute called undef_sets_null (or > something) that's false by default. When true for columns that > allow nulls, > explicitly setting a column to undef would always set it to null, > regardless > of any default value. (My inclination is to make this the case for > both > values from the user and values from the db.)
The implementation needs to tell the difference between a value that is given and one that is not. For example Foo->new() and Foo->new(bar => undef) should have different results if the column bar is defined as allowing null but a default value of 1 IMO, default value should only be used during create when a value is not specified by the user. At all other times the method should return whatever value the object holds. Graham. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
