I just realised there is an odd ‘feature’ that comes into effect if you happen to combine
create_ddl_dir. It’s not technically a bug because it’s technically legitimate features but it causes some odd side effects in my test code. Warnings about drop statements when no table existed.
$ /opt/perl5/bin/prove -l t t/02-xmlcheck.t .... DBIx::Class::Storage::DBI::__ANON__(): DBIx::Class::Schema::deploy(): DBI Exception: DBD::SQLite::db do failed: no such table: phonenumbers [for Statement " -- -- Table: phonenumbers -- DROP TABLE phonenumbers"] at /opt/perl5.10.1/lib/site_perl/5.10.1/Test/DBIx/Class/SchemaManager.pm line 169 (running " -- -- Table: phonenumbers -- DROP TABLE phonenumbers") at /opt/perl5.10.1/lib/site_perl/5.10.1/Try/Tiny.pm line 98 t/02-xmlcheck.t .... ok All tests successful.
I’ve been using Test::DBIx::Class to test my model code and by default it creates an SQLite database in memory so a drop statement at the start didn’t make sense. The actual error messages didn’t actually cause my tests to fail but they weren’t desirable. It turns out that the reason I was getting them was because I’d also done a create_ddl_dir to create schema files for databases, including SQLite and left the files in the dir I was running the tests from. The DBIx::Class code was detecting them and using them to generate the tables. They contained drop statements because they were standard schema’s intended for use with real databases.
As soon as I realised that and moved the schema files into a different directory the drop errors disappeared. As I say, I don’t think this is a bug, more a couple of features interacting in a way that wasn’t what I wanted. I’m just documenting what I found so that when I encounter it again in a couple of months and have forgotten the reason I’ll be able to read why.
Test::DBIx::Class is a really useful module and it makes doing tests of the data layer really simple. It’s worth checking out if you are using DBIx::Class because it makes the cost of doing data tests a lot lower. It’s possible to switch to using a real db if necessary but by default I use the in memory tests most of the time because it means there is no reason not to run the data tests wherever I deploy modules to.