> Your problem is not a database problem, but a presentation problem. > So to keep things clean you should solve it when representing the data and > not in the database interface.
But isn't the problem of translating the database's notion of NULL to Perl the interface's issue? It seems to me that if everyone is writing their own little mapping routines that the interface might wish to add something similar for ease of use-- some good old-fashioned Perl syntactic sugar... > So you could write two special print subs to print rows, or > special subs to > transform rowdata. That's exactly what I'm doing now. I know how to do it, it's just that I'd rather not have to all the time. Mitch > -----Original Message----- > From: M.W. Koskamp [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 04, 2002 11:09 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: mapping NULL values > > > > ----- Original Message ----- > From: "Mitch Helle-Morrissey" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, January 04, 2002 5:22 PM > Subject: RE: mapping NULL values > > > > That is a good way to hide the warnings. Another reason that > I'd like to > be > > able to specify what NULL comes out as is that I may want to > display null > > differently in different applications. For example, Sybase has > bcp which > is > > a bulk upload utility. When I want to make bcp files, they are just > > pipe-delimited text files with NULL fields represented by the > absence of a > > value: > > > > 1||Mitch|December > > > > So in that case I might want to print out NULL values as "". But when I > > print things for humans, (say a web entry screen), I'd rather see "NULL" > > where a null value is. > > > > 1|NULL|Mitch|December > > > > Certainly I could do this mapping myself, but I'd rather not do it every > > place I fetch rows. Also, I'm sure it would be much more efficient for > DBI > > to handle it internally. Especially when we're talking about a lot of > rows. > > And it seems like it wouldn't be that difficult of a thing to add. > > > > Your problem is not a database problem, but a presentation problem. > So to keep things clean you should solve it when representing the data and > not in the database interface. > So you could write two special print subs to print rows, or > special subs to > transform rowdata. > > example: > > print join "|", (null_to_empty(undef, "foo",undef, "bar") ); > print join "|", null_to_text(undef, "foo",undef, "bar"); > > > > sub null_to_text{ > return map{defined $_ ? $_ : "NULL"}@_; > } > sub null_to_empty{ > return map{defined $_ ? $_ : ""}@_; > } > > > > >
