Re: Allow impossible model validation (mainly admin and generic forms)

2015-11-26 Thread Vlastimil Zíma 
General flow for forms should develop to this:

form = MyModelForm(data)
if form.is_valid():
try:
form.save()
except ValidationError, error:
form.add_error(None, error)
else:
return redirect('success')
return render_failure(form)

While handling such case in custom view is simple. But handling this case, 
when using views from Django is completely different level. In generic 
views it is still possible to override `form_valid` to handle 
IntegrityError or other required exception, but it is not possible to do so 
in ModelAdmin 'add_view' and 'change_view'. There it requires rebuilding 
the whole context which is duplication of about 30 lines from '
changeform_view'.

Dne čtvrtek 26. listopadu 2015 13:30:50 UTC+1 Tom Christie napsal(a):
>
> > Append form's non_field_errors with message like
>
> Given that the IntegrityError doesn't occur until the point of .save(), 
> it's not obvious how that'd work in terms of the Forms API.
> You're absolutely correct that there's a class of constraints that can 
> fail here, but it's not evident to me that dealing with these explicitly 
> when required (in practice, fairly rare) isn't a better tack.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c7bf261c-bcf6-4903-bc82-49586bc23875%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow impossible model validation (mainly admin and generic forms)

2015-11-26 Thread Tom Christie 
> Append form's non_field_errors with message like

Given that the IntegrityError doesn't occur until the point of .save(), 
it's not obvious how that'd work in terms of the Forms API.
You're absolutely correct that there's a class of constraints that can fail 
here, but it's not evident to me that dealing with these explicitly when 
required (in practice, fairly rare) isn't a better tack.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/96d28748-5c24-4448-a83a-f0ac51a30946%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow impossible model validation (mainly admin and generic forms)

2015-11-26 Thread Vlastimil Zíma 
Hi guys,

to answer Tim's questions:

> Would Django itself ever raise ValidationError in Model.save()?

That can be possible. Currently I have no clear opinion of where 
IntegrityError and other errors should be changed to ValidationError.

> I wonder how you propose converting something like an IntegrityError from 
the database into an "friendly" exception for the user?

The message doesn't have to be specific. Append form's non_field_errors 
with message like "An unexpected error occured while saving the data. 
Please try again." is in my opinion way better than server error caused by 
unhandled exception. I'm not in favor of re based heuristics to get details 
from integrity error message as noted by Aron.

Vlastik

Dne čtvrtek 26. listopadu 2015 7:34:32 UTC+1 Aron Podrigal napsal(a):
>
> I'm also in favor of some solution here. I used to raise a ValidationError 
> with either a particular field if I was able to extract the particular 
> error via regex matches, or as non_field_errors. That was my best I had 
> instead of resulting in a 5xx. In most cases for example a unique race 
> condition, when the user will resubmit the form it will have the detailed 
> validation errors or pass.
> On Nov 25, 2015 1:57 PM, "Tim Graham"  
> wrote:
>
>> Would Django itself ever raise ValidationError in Model.save()?
>>
>> I wonder how you propose converting something like an IntegrityError from 
>> the database into an "friendly" exception for the user?
>>
>> On Wednesday, November 25, 2015 at 9:23:05 AM UTC-5, Vlastimil Zíma wrote:
>>>
>>> Django assumes that all input data in forms can be validated by 
>>> `Form.is_valid()` which in some cases is not true. Database contraints, 
>>> e.g. unique, can fail even though they are checked. An application may 
>>> require communication with other servers while processing data which can 
>>> lead to errors. But these conditions are not expected by regular Django 
>>> form flow and an attempt to handle these cases results in large overriding 
>>> of default implementation.
>>>
>>>
>>> This topic was previously discussed here 
>>> https://groups.google.com/d/topic/django-developers/rzjpP0byNQo/discussion, 
>>> but discussion was mainly based on race condition in unique check. I'd like 
>>> to reopen the topic because there are other possibilities which may cause 
>>> the possibility of failure after form validation to become real, especially 
>>> if network connection is involved.
>>>
>>>
>>> I suggest Django should provide mechanism which allow handling the 
>>> unexpected failures after form validation, e.g. expect `ValidationError` to 
>>> be raised by `ModelAdmin.save_model`.
>>>
>>>
>>> I started this discussion as a result of wontfix from 
>>> https://code.djangoproject.com/ticket/25777.
>>>
>>>
>>> Vlastik
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1db10ddc-eae6-4f17-a596-b8ce1aa8ef1f%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c80d79ed-518e-44da-903a-6f5ae166e69d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow impossible model validation (mainly admin and generic forms)

2015-11-25 Thread Podrigal, Aron 
I'm also in favor of some solution here. I used to raise a ValidationError
with either a particular field if I was able to extract the particular
error via regex matches, or as non_field_errors. That was my best I had
instead of resulting in a 5xx. In most cases for example a unique race
condition, when the user will resubmit the form it will have the detailed
validation errors or pass.
On Nov 25, 2015 1:57 PM, "Tim Graham"  wrote:

> Would Django itself ever raise ValidationError in Model.save()?
>
> I wonder how you propose converting something like an IntegrityError from
> the database into an "friendly" exception for the user?
>
> On Wednesday, November 25, 2015 at 9:23:05 AM UTC-5, Vlastimil Zíma wrote:
>>
>> Django assumes that all input data in forms can be validated by
>> `Form.is_valid()` which in some cases is not true. Database contraints,
>> e.g. unique, can fail even though they are checked. An application may
>> require communication with other servers while processing data which can
>> lead to errors. But these conditions are not expected by regular Django
>> form flow and an attempt to handle these cases results in large overriding
>> of default implementation.
>>
>>
>> This topic was previously discussed here
>> https://groups.google.com/d/topic/django-developers/rzjpP0byNQo/discussion,
>> but discussion was mainly based on race condition in unique check. I'd like
>> to reopen the topic because there are other possibilities which may cause
>> the possibility of failure after form validation to become real, especially
>> if network connection is involved.
>>
>>
>> I suggest Django should provide mechanism which allow handling the
>> unexpected failures after form validation, e.g. expect `ValidationError` to
>> be raised by `ModelAdmin.save_model`.
>>
>>
>> I started this discussion as a result of wontfix from
>> https://code.djangoproject.com/ticket/25777.
>>
>>
>> Vlastik
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1db10ddc-eae6-4f17-a596-b8ce1aa8ef1f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANJp-yh7HTnVowJx08VVU2dqAk9pSVnd%2B40XXdSeeYnG8LSLbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow impossible model validation (mainly admin and generic forms)

2015-11-25 Thread Tim Graham 
Would Django itself ever raise ValidationError in Model.save()?

I wonder how you propose converting something like an IntegrityError from 
the database into an "friendly" exception for the user?

On Wednesday, November 25, 2015 at 9:23:05 AM UTC-5, Vlastimil Zíma wrote:
>
> Django assumes that all input data in forms can be validated by 
> `Form.is_valid()` which in some cases is not true. Database contraints, 
> e.g. unique, can fail even though they are checked. An application may 
> require communication with other servers while processing data which can 
> lead to errors. But these conditions are not expected by regular Django 
> form flow and an attempt to handle these cases results in large overriding 
> of default implementation.
>
>
> This topic was previously discussed here 
> https://groups.google.com/d/topic/django-developers/rzjpP0byNQo/discussion, 
> but discussion was mainly based on race condition in unique check. I'd like 
> to reopen the topic because there are other possibilities which may cause 
> the possibility of failure after form validation to become real, especially 
> if network connection is involved.
>
>
> I suggest Django should provide mechanism which allow handling the 
> unexpected failures after form validation, e.g. expect `ValidationError` to 
> be raised by `ModelAdmin.save_model`.
>
>
> I started this discussion as a result of wontfix from 
> https://code.djangoproject.com/ticket/25777.
>
>
> Vlastik
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1db10ddc-eae6-4f17-a596-b8ce1aa8ef1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Allow impossible model validation (mainly admin and generic forms)

2015-11-25 Thread Vlastimil Zíma 


Django assumes that all input data in forms can be validated by 
`Form.is_valid()` which in some cases is not true. Database contraints, 
e.g. unique, can fail even though they are checked. An application may 
require communication with other servers while processing data which can 
lead to errors. But these conditions are not expected by regular Django 
form flow and an attempt to handle these cases results in large overriding 
of default implementation.


This topic was previously discussed here 
https://groups.google.com/d/topic/django-developers/rzjpP0byNQo/discussion, 
but discussion was mainly based on race condition in unique check. I'd like 
to reopen the topic because there are other possibilities which may cause 
the possibility of failure after form validation to become real, especially 
if network connection is involved.


I suggest Django should provide mechanism which allow handling the 
unexpected failures after form validation, e.g. expect `ValidationError` to 
be raised by `ModelAdmin.save_model`.


I started this discussion as a result of wontfix from 
https://code.djangoproject.com/ticket/25777.


Vlastik

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b845bfbc-1020-4277-81c5-6fb97c302f98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.