Thing is, I've hit a problem. The process of dumping the old database and reading it into the new format by doing sqlite OLD.DB
Some of the tables in the db contain a bunch of three-digit ISO codes used to identify countries and so on. Quite a few of these codes start with a zero. On checking the newly created database with sqlite, though, I discovered that all the leading zeroes had vanished.
Talking to DrForr on #perl, I discovered that SQLite now has a concept of column types, and so I recreated the tables in question, changing the columns to be TEXT char(3), thinking that this restriction would force it not to consider the values as numbers. But that didn't work:
foreach (@rows)
{
my ($code_alpha2, $code_alpha3, $code_numeric, $name, $dialling_code) = @{$_};
# Yes, this is crap, but I don't care right now:
$code_numeric = '0' . $code_numeric if length($code_numeric) == 2;
$code_numeric = '00' . $code_numeric if length($code_numeric) == 1;
print "country: $code_alpha2 / $code_numeric\n" if $code_numeric =~
my $sth_update = $dbh_new->prepare("INSERT INTO country VALUES (?,?,?,?,?)");
$sth_update->execute($code_alpha2, $code_alpha3, $code_numeric, $name, $dialling_code);
}
The kind of stuff that gets printed to STDOUT is country: bm / 060, but when I check the database in sqlite, it says bm|bmu|60|Bermuda|1441. Still stripping the zeroes!
I've tried a few different approaches, but none have worked. Leon suggested overloading "" to force stringification(?), but I'm finding it extremely hard to understand either what perldoc overload or the Camel have to say about overloading.
Can any of you help?
From The Manual of Zen Buddhism:
"Subhuti, what do you think? Does a Bodhisattva set any Buddha-land in array?"
"No, World-honoured One, he does not."
"Why? Because to set a Buddha-land in array is not to set it in array, and therefore it is known as setting it in array."
I trust that is sufficiently clear.
Open this Book as a Novice
and Finish it as a Pro
Discussed this with richardc. Questions we thought needed answering:
I was reminded for some reason of the bit of Raiders of the Lost Ark where the spirits come out of the Ark of the Covenant and melt people's faces off. We decided in the end it was safer not to open the book at all.
Bot::BasicBot really is so cool. My thanks to all those involved.
We would like to invite you to participate with http://openguides.org/ in this year's Prix Ars Electronica, the foremost international prize for computer-based art.
Top prize: EUR10,000!
Crikey.
I'm honoured to be looking after Iain's code, and I just hope that I do it justice. Requesciat in pace, koschei.
richardc - our release manager here at Fotango - just came over to tell me that our build system was choking whilst running the tests for Locale::Object . After a bit of poking around, we traced the problem down to DateTime::TimeZone , which L::O uses.
It turns out that the build was croaking because when Locale::Object::Country did a DateTime::TimeZone->new(), it needed DateTime . However, my Build.PL doesn't list DT as a pre-req, because DT::TZ doesn't either. Combing through the code, we discovered that DT::TZ has an implicit requirement for DateTime because DateTime::TimeZone::OlsonDB does a DateTime->new() . Not a problem, you'd think, right? Add a dependency for DT. Unfortunately, DT depends on DT::TZ.
Our "solution" was to skip tests for DT::TZ. Not ideal. Anybody have any experience of dealing with this kind of thing?