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);

    [download]
    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.
[reply]
[d/l]
[select]
      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 (?)

      [download]
      will effectively mean 
      INSERT INTO FOO (foo) VALUES (NULL)

      [download]

      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.

[reply]
[d/l]
[select]
        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.
[reply]

In Section Seekers of Perl Wisdom