Unique validator does not raises 500 when it requires a type coercion and it raises an exception

[TrilceAC]

On issue #139 I presented an scenario where unique causes 500 errors because the query to check for uniquenes cannot be performed due to a failed type coercion with PhoneNumberType and phonenumbers.

This pull request with its associated test solves this issue using a reviewed version of the restrictive approach that I proposed. Though it is not perfect, nothing better comes to my mind. If the unique validation cannot be performed, no matter the reason, there is a ValidationError with a customizable message through a new parameter of the Unique validator called message_uncheck. By default, it is set to show the message "Unable to check uniqueness." This causes validation errors instead of 500 errors when invalid data is set on unique fields that require a typer coercion that might raise exceptions.

[kvesteri]

I think a good way to implement this would be to:

1. Use python_type property of the associated TypeEngine / TypeDecorator object and try to coerce the value using the class returned by the python_type and catching errors.
2. You could also check that the associated TypeEngine / TypeDecorator has this python_type property defined and if not then the Unique validator can not be used for that specific type.

By catching all errors when executing the uniqueness check query is bad for a whole bunch of reasons. The error might occur for example if the database connection is lost, if something else in the query fails, if there is bug in the underlying database driver...

[TrilceAC]

Hi,

As suggested, I have tried to implemented a general way to coerce the data when checking for uniqueness, but I couldn't. It seems to me that each TypeDecorator might implement different approaches to coerce data, at least when data comes from a form.

What I have done is to perform a check for PhoneNumberType, trying the type coercion, by means of using a private method, i.e. not the best solution. I no longer try to catch any exception when the query is performed. Instead, I try to do the _coerce that is going to be performed, and I catch the exception PhoneNumberParseException. This works for PhoneNumberType, but is not a general solution for any type.

Advantages:

• No generic except. Only PhoneNumberParseException is catched.

Drawbacks:

• Not a general solution. Other types will require different approaches.

By catching all errors when executing the uniqueness check query is bad for a whole bunch of reasons. The error might occur for example if the database connection is lost, if something else in the query fails, if there is bug in the underlying database driver...

I agree that in general, catching any exception is not the best practice. In this case, I came to the conclusion that any exception, no matter which is the cause, results in a failed validation. In this case, I don't see harmful to catch any exception and raise a ValueError. In the end, the validation is failing and in cases of connection lost or other causes, you won't be able to insert the data.

Having said this, I have removed the except Exception. At the moment of writting, only PhoneNumberParseException is catched.