use of DBI; I am getting multiple error messages mixed in with the correct output.
in [Perl]
|
Prev: FAQ 1.15 Where can I get a list of Larry Wall witticisms?
Next: use of DBI; I am getting multiple error messages mixed in with the correct output.
From: Ben Bullock on 24 Apr 2008 05:59 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. 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? > 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 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?
From: RedGrittyBrick on 24 Apr 2008 06:12 Ted wrote: > On Apr 23, 7:38 pm, "A. Sinan Unur" <1...(a)llenroc.ude.invalid> wrote: >> Ted <r.ted.by...(a)rogers.com> wrote in news:3b842be5-7145-42f6-9f5a- >> ad1c3a50a...(a)x35g2000hsb.googlegroups.com: >> >>> table is returned. However, The correct output is punctuated about >>> every 100 lines by hundreds of error messages: "Use of uninitialized >>> value in printf at k:/MerchantData/MSDB.pl line 34." That is the >>> printf in the for loop within the while loop. This increases the >>> number of lines of output from precisely 529 to more than 1800! That >>> is almost three times as much garbage as there is real data. >> 1. Those are warnings, not errors. The difference matters. >> > Yes, but treating warnings as if they're errors alows one to develop > more robust code. That may be generally true of Perl too but, with Perl, there are a few circumstances where it may be best to suppress specific warnings for a limited scope. I occasionally use @SuppressWarnings("unchecked") in Java because some Java core classes are not generified or because type-erasure renders some type-casts uncheckable at runtime. Treating those as errors (or as bugs in Eclipse) would be wrong IMO. Notwithstanding the above, I find it unhelpful to adopt Java (or C++) habits or principles when writing Perl. >> 2. By default, warnings go to STDERR. > > Right. But the trick is to figure out how to separate STDOUT from > STDERR within Emacs. Doing so on the commandline is trivial using > redirection, but within Emacs? That may be an annoyance I'll have to > live with for now. I use Perl, I don't use Emacs. I think this problem is an Emacs problem and shouldn't be muddled together with discussion here of your concerns about Perl DBI/DBD. -- RGB
From: Ben Bullock on 24 Apr 2008 06:57 On Wed, 23 Apr 2008 21:52:51 -0700, Ted wrote: > On page 155, about half way down the page talking about the > function defined, I see "A scalar that contains no valid string, > numeric, or reference value is known as the undefined value, or undef > for short. Many operations return the undefined value ender exceptional > conditions, such as end of file, uninitialized variable, system error, > and such. This function allows you to distinguish between an undefined > null string and a defined null string when you're using operators that > might return a real null string." Try running the following script to clarify what this means: #!/usr/bin/perl use warnings; use strict; my $a; my $b = ""; print "a is defined\n" if defined($a); print "b is defined\n" if defined($b); Here $b is a "real null string" and $a is undefined. > Here you're confusing me. I agree, given what Wall et al. wrote about > it, comparing undefined to null in Java or C/C++ is a decent analogy, > but not exact. It is more correct to relate it to variables or > identifiers that have been declared but not yet initialized. That's not a good analogy. Again, try the following script: #!/usr/bin/perl use warnings; use strict; my $b = ""; print "1: b is defined\n" if defined($b); undef ($b); print "2: b is defined\n" if defined($b); The undefined value in Perl is assigned to variables but that doesn't mean that undefined equals uninitialized. > Allowing a programming > language to be markedly multivocal is a recipe for confusion, at least > without extensive and pedantic documentation. Well, you're going to be confused then - if you feel that way, maybe it's better not to learn Perl. > But ALL of these concepts are very different from the idea of NULL in > SQL. For example, The book, from Osborne, "SQL: The complete reference" > by James Groff and Paul Weinberg, described it as referring to data that > is missing, unknown, or don't apply. Which seems to be exactly what the undefined value in Perl is, to me. > While NULL in SQL is different from > numeric or string data, I see nothing in the idea that indicates it is a > value that is not part of the normal range of values. Perhaps you can think of Perl's undef as being part of the normal range of values, too. > I see nothing similar between the idea of NULL in SQL and either null or > undefined in the other languages. That's odd, because the more you talk about SQL's NULL, the more it looks like Perl's undefined value to me. > But if you see the idea of the empty set as being integral to the > idea of null as it exists in SQL, then the relation with either null or > undefined in C++, Java or Perl becomes even more distant because the > relevant containers in C++ and Java make no direct use of nulls in > handling empty sets as far as I can see. You seem to be getting lost in your own verbosity here - you start this sentence including Perl and by the end of it you are only talking about C++ and Java. > In both cases, the containers > have member functions that return true if the set is empty and fals > otherwise. But now, as far as I can figure out, you're not talking about Perl any more anyway.
From: Ted on 24 Apr 2008 07:56 On Apr 24, 1:17 am, Jürgen Exner <jurge...(a)hotmail.com> wrote: > Ted <r.ted.by...(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. > 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. 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. Ted
From: Ted on 24 Apr 2008 08:08
On Apr 24, 5:59 am, Ben Bullock <benkasminbull...(a)gmail.com> wrote: > 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. > That perl provides an easy way to test for a variable being undefined is a neat capability, as you're thereby able to test for metadata that can change at runtime. But that has little to do with the meaning of what it is for a variable to be undefined. > > 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. 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? > It seems completely different from Wall et al.'s description of them. Or are you going to say that what they wrote was wrong or misleading and that I shouldn't have believed them? My answer as to what value to give a perl scalar is given below in text you quoted in brief, and in more detail by Abigail later on in this thread. > > 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 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? See Abigail's answer. for such details. She's right on the money. Ted |