More verbose error messages when failing to parse database results in…

[MaxGabriel]

…to Persistent records

Closes #689

Previous error message, as reported in #689:

"get UserKey {unUserKey = SqlBackendKey {unSqlBackendKey = 1}}: field foo: int Expected Integer, received: PersistText "foo"

New error message:

Error when calling get with key: UserKey {unUserKey = SqlBackendKey {unSqlBackendKey = 1}}. Failed to create User because of error: Couldn't parse field foo from database results: Tried to parse Haskell type Int, expected integer from database, but received: PersistText "foo". Potential solution: Check that your database schema matches your Persistent model definitions. Potential solution: If this is a custom PersistField instance, check that it's correct.

This is maybe a little bit more verbose than ideal, imo, but I lean towards a verbose error message because you should only see this error message if your PersistField instances are incorrect, or your database schema doesn't match your persist model definitions (afaik). It's also kind of hard to make a clean error message because the error is constructed from several different locations in the code.

Specific improvements:

1. In the message: field foo: int Expected Integer, received: PersistText "foo", it's totally unclear what int is, and calling it int doesn't suggest that it's a Haskell type (vs Int).
2. Make recommendations about potential solutions. Afaik these are the only solutions to this problem?
3. Highlight the function being called. I think because it's just get it's hard to realize that function is the root of the problem.

Behavior change: A handful of the PersistField parsing functions called error instead of returning Left Text. I think since the vast majority returned Left that it's fine to change this. I also can't imagine anyone is relying on the error vs left distinction, especially because higher level functions like get just call error themselves on a Left.

[gregwebs]

awesome, looks like just a doc conflict with master now.