Migration failure needs to be obvious and clean

[steder]

Migration failure needs to be obvious and clean

[ldanielburr]

I agree with the title of this issue, but vehemently disagree that return integer codes is a good, or even decent, means of accomplishing this aim. In order to provide "an appropriate non-zero value on failure" means parsing the OperationalError anyway, so why not convert it to a goose.exceptions.SomeAppropriateException, with a "more informative and user-friendly" message attribute?

[steder]

I'm not advocating that the return code be used by people using Goose as a library within their startup process.
I'm also not thinking that they should use a return code ("Just run goose and then "echo $?" to check the return code!").

I'm just thinking that any traceback is irrelevant in the case of an error in a SQL file but the migration should still fail in a way that is unambiguous for a runner like Buildbot or Jenkins.

http://buildbot.net/buildbot/docs/0.8.5/manual/cfg-buildsteps.html

[ldanielburr]

I'm not quite with you yet, though I agree with what you said regarding buildbot/jenkins. What I don't understand is the phrase "any traceback is irrelevant in the case of an error in a SQL file"; it seems pretty relevant to me. Sure the database driver is the thing that actually raises the OperationalError, or what-have-you, but I think it is no different than raising OSError when performing a file-system operation: I still want to know why the error was raised, and the traceback will contain the actual exception message (from the rdbms in this case), and I would want to know that.

[steder]

Yeah, I see your point.
On Mar 11, 2012 1:34 PM, "L. Daniel Burr" <
[email protected]>
wrote:

I'm not quite with you yet, though I agree with what you said regarding
buildbot/jenkins. What I don't understand is the phrase "any traceback is
irrelevant in the case of an error in a SQL file"; it seems pretty relevant
to me. Sure the database driver is the thing that actually raises the
OperationalError, or what-have-you, but I think it is no different than
raising OSError when performing a file-system operation: I still want to
know why the error was raised, and the traceback will contain the actual
exception message (from the rdbms in this case), and I would want to know
that.

---

Reply to this email directly or view it on GitHub:
#16 (comment)