Re^2: Code cleanup; how best to deal with: defined(%hash) is deprecated at... (defined--)

in reply to Re: Code cleanup; how best to deal with: defined(%hash) is deprecated at... (defined--)
in thread Code cleanup; how best to deal with: defined(%hash) is deprecated at...

The only comment here that I don’t strongly-agree with, is the one about a database-column being not null default ''. Although it is a bit of a pain to deal with the difference in code, there is nonetheless an important difference in meaning. The absence of any value is not the same as an empty-string value. The latter, to me, implies that “the value is known, and it is known to be an empty-string.” Queries that might be run by clients entirely separate from this application, e.g. SELECT COUNT(colname) issued by some report-whatnot, would be thrown-off considerably by empty-string values, being lured into counting something that more-properly “isn’t there.”

Mind you, it is not that I categorically-disagree with this practice; merely that I often-do.

Beyond that, a series of very excellent points; upvoted.

Comment on Re^2: Code cleanup; how best to deal with: defined(%hash) is deprecated at... (defined--)

Replies are listed 'Best First'.
Re^3: Code cleanup; how best to deal with: defined(%hash) is deprecated at... (defined--) by choroba (Cardinal) on May 22, 2014 at 11:21 UTC
You probably missed the if the empty string doesn't have special meaning part that describes, one might think that a bit more laconically than needed, exactly the conditions you mentioned in your post. لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply]
Re^3: Code cleanup; how best to deal with: defined(%hash) is deprecated at... (defined--) by herveus (Prior) on May 22, 2014 at 15:58 UTC
Howdy! Some databases consider the empty string to be NULL. I'm looking at you, Oracle. Last time I looked, that execrable behavior is contrary to the SQL standard. yours, Michael	[reply]
Re^3: Code cleanup; how best to deal with: defined(%hash) is deprecated at... (null) by tye (Sage) on May 22, 2014 at 14:19 UTC
From a relational database theorists' perspective, I would have preferred to declare "`not '' default null`" but that isn't supported so simply or easily. From a practical perspective, I actually ended up preferring the route we went. A quick aside: The behavior of sum() and avg() when given values that are null makes perfect sense. But I think count() would have been better implemented as count(BOOL) so one would write things like count(foo <> '') or count(foo is null). Then avg(foo) would be roughly sum(foo)/count(foo is not null). I find the behavior of count(blah) to fairly often be a source of mistakes. And I also find the desire for "count how many times this isn't null" to be pretty rare in practice. So I was happy to avoid (the more frequent but still somewhat rare but also more problematic, IME) problems like "where foo <> 'bar'" skipping null values. - tye	[reply] [d/l]

In Section Seekers of Perl Wisdom