Re: use of DBI; I am getting multiple error messages mixed in with the correct output.

On Apr 23, 11:10 pm, Martien Verbruggen <m...@xxxxxxxxxxxxxxxxxx>
wrote:
On Wed, 23 Apr 2008 18:24:31 -0700 (PDT),
        Ted <r.ted.by...@xxxxxxxxxx> wrote:

On Apr 23, 6:31 pm, Joost Diepenmaat <jo...@xxxxxxxxx> wrote:
Ted <r.ted.by...@xxxxxxxxxx> 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?

OK. You're absolutely right.

I got my understanding of undefined from the book, published by
O'Reilly, "Programming Perl" by Larry Wall, Tom Christiansen and
Randal Schwartz. 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." From what I'm
reading here, it seems my understanding of undefined is not far off
the mark.

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.

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. In fact,
Wall et al. explicitly relate it to uninitialized variables (the very
first sentence I quoted above). One can, in C++, forward declare a
class, which then allows pointers to the class to be declared, but all
one knows, until the definition of the class is provided, is that the
class exists, and so a pointer to an instance of the class can be
declared, but it can't really be used with out the defintion.
Similarly, you can declare functions with prototypes, which can be
called, but you better be sure to link to an object file that provides
the definitions or your linker will complain. But bugs where a
variable is used before it is initialized can be a nightmare to track
down because the problem may only manifest itself sometimes. NULL, in
C++, is specifically a value of 0 given to a pointer. An
uninitialized variable can contain random bits, though the standard
was changed so that you could use a slightly different declaration
that initializes a pod variable to 0. A variable in Java is given a
value of null until it is given an instance of the type of variable it
was defined to represent. It is also clear from what Wall et al. said
that undef can play a role similar to the 'end' iterator defined for
all of the containers in the standard C++ library. I am not exactly
happy with that notion because it is again a very different concept
from that of a null pointer or an uninitialized variable, but it is
admittedly functional. Allowing a programming language to be markedly
multivocal is a recipe for confusion, at least without extensive and
pedantic documentation.

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. There is some
debate about it with some advocating avoiding it at all costs and
others avocating wide use of it and even suggesting the term be
extended to have different null indicators to allow one to distinguish
between, e.g. data that is unknown vs data that doesn't apply. 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. In a table that handles returns on investment for
exchange traded funds for various time frames with columns
representing monthly, quarterly, annual and five year returns, the
column containing five year returns would probably have a model value
of NULL, since the majority exchange traded funds are younger than
five years old. In this specific case, the idea is that a five year
return is not applicable to funds that are not yet five years old.
Yet, the numbers of exchange traded funds has been continually
increasing and it is just a matter of time until that column IS
applicable.

I see nothing similar between the idea of NULL in SQL and either null
or undefined in the other languages.

Both Java and C++ have containers that support set theoretic
operations. But I see nothing specific to those containers and the
algorithms they support that relates to either null or undefined in C+
+ or Java, and I'd have to think about the extent to which they
provide a concept comparable to the idea of NULL in SQL. I can see,
though, how one could easily emulate the idea of NULL as found in SQL
using these containers with a UDT defined to be able to assume a
"null" value and to behave the way NULLs behave in SQL when they have
the null value defined for them. Doing it this way, though, has
virtually nothing in common with the idea of null as it exists in
either C++ or java. Unless you want to relate the SQL idea of NULL to
the empty set, I do not see any necessary relatin between programming
set theoretic algorithms and the idea of null. 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. In both cases, the containers have member functions
that return true if the set is empty and fals otherwise.

SQL NULL maps, IMO, very well to Perl undef.

Unless you can explain how the ideas can be reconciled, I can not
agree. I see nothing in common between them.

Thanks

Ted
.

Relevant Pages

  • Re: Is perl better? :(((
    ... >> Wasthe original PERL script hitting an Oracle database? ... >> Did you run an explain plan on your Oracle SQL? ... Java and perl on another. ...
    (comp.lang.java.databases)
  • Re: Is perl better? :(((
    ... >> Wasthe original PERL script hitting an Oracle database? ... >> Did you run an explain plan on your Oracle SQL? ... Java and perl on another. ...
    (comp.lang.java.programmer)
  • Re: Is perl better? :(((
    ... >> Oracle on one box, Java and perl on another. ... See previous answer about SQL. ...
    (comp.lang.java.databases)
  • Re: Is perl better? :(((
    ... >> Oracle on one box, Java and perl on another. ... See previous answer about SQL. ...
    (comp.lang.java.programmer)
  • Re: SQL
    ... Persistence access is the abstraction, ... However, UML is just one of many OOA/D notations proposed, so it is an implementation of an OOA/D notation. ... Note that I was careful to say that SQL is a solution to persistence /access/ when the data is represented in RDB form. ... Sounds a little bit like Java and the JVM.... ...
    (comp.object)