Re^2: DBD::mysql Unusual Behavior

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.

Comment on Re^2: DBD::mysql Unusual Behavior Select or Download Code

Replies are listed 'Best First'.
Re: Re^2: DBD::mysql Unusual Behavior by bart (Canon) on Aug 23, 2002 at 20:13 UTC
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]
Re^4: DBD::mysql Unusual Behavior by tadman (Prior) on Aug 23, 2002 at 20:39 UTC
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]