Subject: | v0.06000: UNIQUE constraint on SQLite can't be re-deploy()ed |
Date: | Wed, 9 Jun 2010 19:45:28 -0700 |
To: | "bug-DBIx-Class-Schema-Loader [...] rt.cpan.org" <bug-DBIx-Class-Schema-Loader [...] rt.cpan.org> |
From: | David Giller <dave [...] pdx.net> |
I've checked that this works in v0.05003, but breaks in v0.06000 and later.
It appears that disambiguation naming changes for UNIQUE constraints, at least on SQLite databases, cause constraint names given to add_unique_constraint() to use reserved sqlite_* identifier names.
Simple SQLite table:
CREATE TABLE users (
id INTEGER PRIMARY KEY AUTOINCREMENT,
username TEXT UNIQUE,
email TEXT,
password TEXT,
last_modified DATETIME
);
Up to v0.05003, this generates:
__PACKAGE__->add_unique_constraint("username_unique", ["username"]);
Beginning with v0.06000, it generates:
__PACKAGE__->add_unique_constraint("sqlite_autoindex_users_1", ["username"]);
This can't be ->deploy()ed on SQLite. Message:
DBIx::Class::Storage::DBI::__ANON__(): DBIx::Class::Schema::deploy(): DBI Exception: DBD::SQLite::db do failed: object name reserved for internal use: sqlite_autoindex_roles_1 [for Statement "CREATE UNIQUE INDEX sqlite_autoindex_roles_1 ON roles (role)"] at script/deploy.pl line 20
Perl5.8.9, developing for Catalyst 5.80024 and a fresh set of CPAN libs built from Catalyst::Devel and DBIx::Class::Schema::Loader.
Thanks,
Dave