On 9/6/07 10:01 PM, Ask Bjørn Hansen wrote: > We have some columns that are NULL but with a specified default value > (for example "0"). > > deleted => { type => 'integer', default => '0' }, > > Sometimes we need to set it to undef/NULL (a valid value), but RDBO > unhelpfully resets that to the default value ("0"). > > Why does it override my explicit request to make it NULL?
The problem is deciding when to use the default value. In RDBO, the default value is used when the column has an undefined value. Unfortunately, undef is also used to represent nulls. The only solution I see is to use a new "special" value for null. Something like: $o->foo(Rose::DB::Object->NULL); which is now clearly distinguished from a value of undef (which would still trigger the use of the default). 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. (Checking for the existence of a hash key in the object is a non-starter because there's no consistency to column value hash key existence in RDBO objects.) I don't like any of those choices: too much trouble in the common case to enable what I imagine is a rare case (yours, unfortunately). Any other solutions? (Hm, I suppose a force_column_value() Helper method that does evil things internally could be combined with an on_set trigger...) -John ------------------------------------------------------------------------- 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