Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re: DBD::mysql Unusual Behavior

by BrowserUk (Pope)
on Aug 23, 2002 at 11:22 UTC ( #192305=note: print w/replies, xml ) Need Help??

in reply to DBD::mysql Unusual Behavior

Probably way off here, but isn't the correct way to test for the existance of a key exists rather than defined?

Doesn't the use of defined($pair->{unknown key} cause that unknown key to be autovivified? )

That's what I seem to remembering reading somewhere. I'll update if I find the reference. Not sure if that is the cause of your problem though.

What's this about a "crooked mitre"? I'm good at woodwork!

Replies are listed 'Best First'.
Re^2: DBD::mysql Unusual Behavior
by tadman (Prior) on Aug 23, 2002 at 17:40 UTC
    The correct way to check for the presence of a key is to use exists. You'll note, though, that these keys exist since they're from the keys call in the foreach. The concern is that the value will be undefined which is going to generate warnings if used.

    Now regarding this so-called autovivification. People get so paranoid about that sort of thing that they don their tin-foil hats at the merest hint of trouble. It's a lot harder to do than you think. Merely thinking of a key is not enough:
    use Data::Dumper; my $foo = {}; 1 if (defined($foo->{bar})); print Dumper($foo); 1 if (defined($foo->{bar}->{baz})); print Dumper($foo);
    The second one causes autovivification since you're actually extending some pseudo-predefined structure. You can't dereference an undefined value, so it just makes one up for you.
      The concern is that the value will be undefined which is going to generate warnings if used.

      Eh, no. Not in this particular case, anyway. The thing is that DBI's placeholder mechanism will convert every undef into the unquoted string "NULL", so that

      INSERT INTO FOO (foo) VALUES (?)
      will effectively mean

      And some people's database setup will complain about that, if the field isn't allowed to be NULL. Personally, I like NULLs in my databases, for values that indeed have no value.

        The NULL fields actually consume an astounding extra bit per record, so while they're convenient and all, if the difference between "empty" and NULL is trivial, it's often easier to just throw in an empty value.

        Since the column in question was not allowed to be NULL, you're required to check before INSERTion.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://192305]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2020-10-21 16:52 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (222 votes). Check out past polls.