|Subject:||Schema deployment masks errors|
Attempting to deploy a schema masks any errors that may occur whilst deploying the schema, which makes the viable testing route: 1. Deploy schema 2. Poke at the database to see if that succeeded. This isn't optimal and is a known issue. From #dbic-class: 21:27 < idn> So is there a good way to work out if $schema->deploy has succeeded as it doesn't seem to have a return value defined? 21:32 < idn> The source for DBIx::Class::Schema has no return in the deploy function 21:32 <@mst> um 21:32 <@mst> it delegates to ->storage->deploy 21:32 <@mst> trouble is ... we don't really have a "has succeeded" measure 21:32 <@mst> since deploy tends to warn-and-skip on errors 21:33 <@mst> due to many databases not having a CREATE table IF EXISTS type mech 21:37 < idn> Though I would have thought returning the value returned by ->storage->deploy was probably the right thing, and then those that can work it out can pass it back 21:40 < shadowpaste> "ribasushi" at 220.127.116.11 pasted "backlog for idn about very same issue" (3 lines) atContents of shadow paste: [03:03:47] <riba> dukeleto: the folks that wrote deploy()s initial implementation decided to work around sqlt deficiencies by simply ignoring any deploy-time errors, converting them to warnings [03:04:11] <riba> dukeleto: 4 years later the default of "mask errors away" is there to stay [03:04:28] <riba> dukeleto: however I'd be delighted by a patch that adds an on_error handler or somesuch to deploy() Further notes from ribasushi: 21:45 <riba> what I meant is have deploy recognize an extra option that takes a coderef that gets passed any DBI exception 21:45 <riba> and it is up to the coderef to propagate said exception or to mask it away 21:45 <riba> in abscence of such handler - deploy falls back to its default of masking everything away 21:47 <riba> the actual eval lives in ::Storage::DBI::deploy 21:47 <riba> (not Schema::deploy) There's the notes and the details of the bug. I'll try and have a look at this but I suspect it might well be beyond me! Thanks guys, Ian.