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: Martien Verbruggen on 23 Apr 2008 23:10 On Wed, 23 Apr 2008 18:24:31 -0700 (PDT), Ted <r.ted.byers(a)rogers.com> wrote: > On Apr 23, 6:31�pm, Joost Diepenmaat <jo...(a)zeekat.nl> wrote: >> Ted <r.ted.by...(a)rogers.com> writes: >> >> �[ on the conversion of NULL fields to <undefined> ] >> >> > This would be a useful tidbit to add to the documentation. �I hadn't >> > expected a mature library like DBI to behave like this. >> >> Well, it is the most DWIM way of representing NULL values in perl. >> > As I explained to Xho, it is wrong. My understanding of undefined in > Perl was to relate it to uninitialized values in Java or C++. You Your whole argument seems to be based on this assumption. I'm pretty sure that that assumption is wrong. Could you tell us what that assumption is based on? And if that was the only reason for the undef value to exist, why does the undef function exist? Comparing it to null in Java or NULL in C or C++ is probably a good analogy. In all those cases the value is a special one that carry a meaning that is close to the null value in SQL: A value that is not part of the normal range of values. The fact that nulls in SQL have special 'handling' does not change that. If Jave or C has set operations, then they would need to deal with null in very much the same way, and if Perl has them, it would probably do similar things to undef. SQL NULL maps, IMO, very well to Perl undef. If you still think the DBI is broken, instead of you having the wrong idea of what undef means, you should probably have this argument with the DBI developers, who will probably be much better be able to explain to you why it is not broken. Martien -- | Martien Verbruggen | | "Mr Kaplan. Paging Mr Kaplan..." |
From: J�rgen Exner on 24 Apr 2008 01:17 Ted <r.ted.byers(a)rogers.com> wrote: >It is more correct to relate it to variables or >identifiers that have been declared but not yet initialized. No. An unitialized variable can have any value. Mabye a left-over from a previous run, maybe some temporary result that was computed a while ago and left on the stack or whatever. It is mostly a concession to the laziness of programmers as well as some security concerns that nowadays runtime environments initialize declared variables with 0 or some similarly reasonable default. Undef on the other hand is a well defined, very specific value, which you can even set explizitely and test against. You cannot 'reuninitialize' a variable in e.g. C after it was assigned a value. jue
From: Abigail on 24 Apr 2008 07:10 _ Ben Bullock (benkasminbullock(a)gmail.com) wrote on VCCCL September MCMXCIII in <URL:news:fuplm6$7nl$1(a)ml.accsnet.ne.jp>: %% On Wed, 23 Apr 2008 18:24:31 -0700, Ted wrote: %% %% > My understanding of undefined in %% > Perl was to relate it to uninitialized values in Java or C++. You %% > declare a variable, but then attempt to use it before you define it %% > (i.e. give it a value). %% %% I don't know Java, but uninitialized values in C++ are completely %% different from undefined values in Perl. An uninitialized C++ variable %% just contains random garbage, but Perl's undefined values are something %% meaningful, i.e. you can test whether a variable is undefined or not. %% %% > The idea of NULL in SQL is very different. It %% > IS a valid value that can be given to variables or to fields in specific %% > rows, where the table definition allows it. %% %% So it sounds just like an undefined value in Perl. Up to there, yes. But it behaves quite differently. Undefined values in Perl become 0 or the empty string if the context requires so. But not so with SQL NULLs (see below). %% What value would you %% give a Perl scalar to represent an SQL null, if not the undefined value? %% A string saying "NULL"? A special "NULL" object? What would their %% advantage be over just Perl's regular undefined value? Well, there would be some advantages of using a special NULL object instead of 'undef'. Because an SQL NULL behaves differently from an undef. For instance, when doing arithmetic, an 'undef' behaves like a 0, while an SQL NULL behaves like a NaN: 3 + NULL == NULL (SQL) 3 + undef == 3 (Perl) 3 + NaN == NaN (Perl) Unfortunally, there's no NaN equivalent for strings, and when you get something out of a database, DBI cannot know whether it's going to be used as a string, or as a number. %% > NULLs in SQL carry a very %% > specific meaning, and require very specific behaviours when handling %% > them. To translate this into a language like Java or C+ +, I would %% > write a class that provides for the same meaning and behaviours that %% > would be familiar to a SQL programmer. Had I known that the DBI was %% > broken in terms of translating database nulls into <undefined> %% %% I really do not think that it's broken. I'd say, mapping SQL NULLs to undef was a choice. It's often convenient, but can be surprising if you're used to SQL NULLs and the wrong choice if you need the same behaviour. Another choice would have been NaN, but that makes string handling more cumbersome. %% > 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). Abigail -- $_ = "\nrekcaH lreP rehtona tsuJ"; my $chop; $chop = sub {print chop; $chop}; $chop -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> ()
From: Joost Diepenmaat on 24 Apr 2008 08:14 Ted <r.ted.byers(a)rogers.com> writes: > Yes, an uninitialized variable can contain random bits, or garbage, > for whatever reason, but If you are going to say undef is a specific > value, how do you account for Wall et al writing "A scalar that > contains no valid string, numeric, or reference value is known as the > undefined value, or undef for short." That sure looks like a > description of a variable that has not yet been initialized. But it *has* been initialized. All scalars that aren't assigned a value are initialized to "undef", which *is* a value (the quote explicitely states that) and corresponds most closely to the null value in C++ / Java et al. > In all of my code, in whatever language, I always initialize my > variables to 0, or some other reasonable default, as a matter of > course. Doing so prevents nasty surprises that may result from using > a variable that has not been initialized and is easily tested for. > That seems quite different from the idea of someting being undefined. That's fine in C, but in perl the interpreter already does this for you as I described above. Of course that assumes the undef value is actually a useful default for your algorithm. Seems to me you're taking the word "undefined" too literal (for perl). It's not undefined as in "the consequences of doing X are undefined". It's undefined as in "has the default (null) value because it's not been assigned anything else". -- Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
From: Abigail on 24 Apr 2008 09:41
_ Ben Bullock (benkasminbullock(a)gmail.com) wrote on VCCCL September MCMXCIII in <URL:news:fupu4i$8t8$1(a)ml.accsnet.ne.jp>: `` On Thu, 24 Apr 2008 11:10:05 +0000, Abigail wrote: `` `` > Well, there would be some advantages of using a special NULL object `` > instead of 'undef'. Because an SQL NULL behaves differently from an `` > undef. For instance, when doing arithmetic, an 'undef' behaves like a 0, `` > while an SQL NULL behaves like a NaN: `` > `` > 3 + NULL == NULL (SQL) `` `` I'm guessing that when we subsequently try to use this value somewhere, `` then we have an unhappy consequence. Depends on how you use it. But that already happens in Perl as well, for example, @{undef} also leads to unhappy consequences (if you've turned on strict). `` > 3 + undef == 3 (Perl) `` `` This produces the kind of error message the original poster's query was `` about. `` `` > 3 + NaN == NaN (Perl) `` `` OK, but I can't see the advantages of translating the SQL NULL into a `` special Perl object unless we also translate all the SQL strings into `` special SQL string objects which behave just like SQL strings, and SQL `` number objects which behave just like SQL numbers, etc. etc. I don't see `` the value in it. If he wants to get SQL behaviour then why not just stick `` with manipulating the data inside the database via SQL statements in DBI, `` rather than pulling the values into Perl variables and then imposing a `` kind of "fake SQL" behaviour on the Perl variables. Ah well, if Perl+CPAN only had things you could see the advantage of... I won't object if the OP writes an extension to the DBI that used special NULL objects. Abigail -- perl -Mstrict='}); print "Just another Perl Hacker"; ({' -le1 |