use of DBI; I am getting multiple error messages mixed in with the correct output.
in [Perl]
|
Prev: use of DBI; I am getting multiple error messages mixed in with the correct output.
Next: FAQ 1.11 When shouldn't I program in Perl?
From: Joost Diepenmaat on 24 Apr 2008 09:45 Ted <r.ted.byers(a)rogers.com> writes: > But this still seems quite different to what NULL means in SQL. How > would you explain the rationale for that mapping? Abigail has already > explained the reason for my surprise at this. I think that undef is a good choice for NULL if you want to map SQL values to "native" perl values. undef is /conceptually/ the closest perl has to SQL NULL. If on the other hand, you want values that /behave/ like their SQL counterparts, that would mean that most values would behave differently from the built-in perl types. And that would make it much more cumbersome to use data from the database in perl code that doesn't expect that behaviour (which would be almost all reusable code). It would probably not be too much work to wrap DBI to return a special NULL object instead of undef, for example, but I think the current mapping makes the most sense for a relatively low-level interface like DBI. -- Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
From: Abigail on 24 Apr 2008 09:55 _ Joost Diepenmaat (joost(a)zeekat.nl) wrote on VCCCL September MCMXCIII in <URL:news:877iene598.fsf(a)zeekat.nl>: ^^ Ted <r.ted.byers(a)rogers.com> writes: ^^ ^^ > But this still seems quite different to what NULL means in SQL. How ^^ > would you explain the rationale for that mapping? Abigail has already ^^ > explained the reason for my surprise at this. ^^ ^^ I think that undef is a good choice for NULL if you want to map SQL ^^ values to "native" perl values. undef is /conceptually/ the closest perl ^^ has to SQL NULL. No, 'undef' is a compromise. When using numbers, and numerical operators, NaN is much closer to an SQL NULL than undef is. However, Perl has only typed values, and mixes and matches strings and numbers without explicite casting. And there isn't a string alternative for NaN. ^^ If on the other hand, you want values that /behave/ like their SQL ^^ counterparts, that would mean that most values would behave differently ^^ from the built-in perl types. And that would make it much more ^^ cumbersome to use data from the database in perl code that doesn't ^^ expect that behaviour (which would be almost all reusable code). Really? I claim that good code, that is, code that uses warnings, will have to deal with 'undef's explicite anyway, because most operators will issue a warning if one or more of their arguments is undefined anyway. ^^ It would probably not be too much work to wrap DBI to return a special ^^ NULL object instead of undef, for example, but I think the current ^^ mapping makes the most sense for a relatively low-level interface like ^^ DBI. Abigail -- perl -wle 'eval {die [[qq [Just another Perl Hacker]]]};; print ${${${@}}[$#{@{${@}}}]}[$#{${@{${@}}}[$#{@{${@}}}]}]'
From: Ted Zlatanov on 24 Apr 2008 10:56 On Wed, 23 Apr 2008 14:40:14 -0700 (PDT) Ted <r.ted.byers(a)rogers.com> wrote: T> This would be a useful tidbit to add to the documentation. I hadn't T> expected a mature library like DBI to behave like this. I do not, for T> example, have to go through any such extra hoops when using JDBC with T> JSF. If a particular record set contains nulls in one or more columns T> in one or more records, JSF automagically displays it as an empty T> string; something I have modified on occassion to display the string T> "N/A". I saw your discussion with the others, it covered all the bases. I agree with Abigail (unsurprisingly), but I also think the current DBI approach is the best compromise between ideology and pragmatism. T> You needn't worry about rewriting the whole thing as I'll be doing T> that anyway as I learn to translate more of what I know from C++,Java T> and SQL into Perl. But perhaps you could give me a break and make T> some suggestions as to what improvements you'd recommend and where to T> look for details in the documentation. Use an options hash with Getopt::Long. Instead of $$var[$i], use $var->[$i]. Learn about join, map, and grep. Have fun. Always look for a shorter, smarter way to do something. T> And one thing I haven't found yet, which I am sure must be there T> somewhere, is how to set up a bulk insert. Can you point me in the T> right direction to see how to do that using DBI? Bulk inserts are annoyingly hard to do in a generic way. You've got to do it with the database's particular facility. Postgres, for example, has a statement that will import a file; Sybase has an entirely external utility for this task and no internal functionality. Ted
From: xhoster on 24 Apr 2008 10:58 Abigail <abigail(a)abigail.be> wrote: > _ > > %% > I'd have > %% > considered developeing an extension to DBI; one that included a NULL > %% > class that would serve the needs of database programmers. > %% > %% What would it do, exactly? > > If I were to implement is, an object of such a class would have > overloaded all operations and return another NULL object for all > operations, except when comparing it with NULL (in which case it would > return a true value). But in SQL, comparing NULL with NULL gives NULL, not true. At least with ordinary comparison operators. Also, for the "and" and "or" operators, sometimes they give non-NULLs. NULL and false = false NULL and true = NULL NULL or false = NULL NULL or true = true Xho -- -------------------- http://NewsReader.Com/ -------------------- The costs of publication of this article were defrayed in part by the payment of page charges. This article must therefore be hereby marked advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate this fact.
From: A. Sinan Unur on 24 Apr 2008 13:01
Ted <r.ted.byers(a)rogers.com> wrote in news:064ae74c-23e2-4034-828d-4c22ee292381(a)l42g2000hsc.googlegroups.com: > On Apr 24, 10:56�am, Ted Zlatanov <t...(a)lifelogs.com> wrote: .... >> I saw your discussion with the others, it covered all the bases. �I >> agree with Abigail (unsurprisingly), but I also think the current DBI >> approach is the best compromise between ideology and pragmatism. >> > She is a gem, isn't she?!! s/[Ss]he/he/g Sinan -- A. Sinan Unur <1usa(a)llenroc.ude.invalid> (remove .invalid and reverse each component for email address) comp.lang.perl.misc guidelines on the WWW: http://www.rehabitation.com/clpmisc/ |