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
