Finding an object without passing a valid UUID gives a Postgres error

[jgaskins]

Since we default to saving objects as UUIDs, passing in a string that is not in a UUID format will cause Postgres to throw a tantrum, which raises an exception.

We shouldn't let the PG gem error bubble up to the user. This should be rescued in the Postgres#retrieve method. It should probably just return nil the same as if we asked for an id that didn't exist in the DB.

[acook]

I've been a big fan of wrapping errors in objects (or other Exceptions) and logging them to make debugging easier. The end user wouldn't typically see them unless $DEBUG or some other flag was set. I use all_errors_are_fatal as the flag sometimes, defining a bang method to enable it a predicate method to check its state.

[jgaskins]

I agree, wrapping exceptions in our own exceptions would be a great thing to do. I think the base PG exception is PG::Error, so if we can't handle it gracefully, we could rescue that, wrap the exception and raise the wrapped object.

I'm not so sure now that the UUID exception can be handled gracefully. The way we're handling querying tables that don't exist is just to return nothing. If you're passing in an id, none of the ids in the database are going to match, but if you're not checking equality an empty list is not what you're looking for:

mapper.select { |obj| obj.id != 42 }

That query should return everything in the database because nothing matches that non-UUID value. Maybe we should raise an exception in this case because we can't fulfill this query.