>
> For whatever reason, if a field is not provided in the request data, then
> Django is assuming it is an empty string and overwriting existing data.
>
I recently discovered that if the model field has the *default* attribute,
then the non-existent fields in the POST data will not be populate
Maybe it would be helpful to have an option where it errors if
(non-boolean) fields are non-existent in the POST data? (Though I have some
GET-forms where I would not want that behavior) Maybe I could somehow set
allow_missing_fields = True in that case?
On Tue, Jan 23, 2018 at 4:56 AM, Tai Lee w
>From my perspective, this issue is about silent data loss, which is about
one of the worst bugs you can have and one that Django typically tries very
hard to avoid or fix, even if it breaks compatibility.
It is extremely easy to cause silent data loss with the behaviour being
discussed. For whate
On 01/22/2018 06:03 PM, Anupam Jain wrote:
Wow - I just realised that we have been losing data for sometime on our
web platform since there were some fields in the ModelForm that were
hidden and not being sent. They were all being overwritten as blank
values. Thank God, we use django-reversion
Wow - I just realised that we have been losing data for sometime on our web
platform since there were some fields in the ModelForm that were hidden and
not being sent. They were all being overwritten as blank values. Thank God,
we use django-reversion to track changes. Will take us sometime to r
I think Ian demonstrated exactly why this should not go in and that is not
all forms are ModelForms. Imagine writing a REST API which allows for an
optional format parameter for GET requests which is validated by a Django
form. With the inclusion of this proposal all clients would be forced to
spec
> If optional fields are
> left off the HTML form deliberately, without change the Form class or
> the view code, this is exactly when data loss will currently occur.
> I think you are confusing optional as in "may not be specified by the
> user" with optional as in "may not be processed by the for
On 12 ene, 14:07, Ian Clelland wrote:
> On Thu, Jan 12, 2012 at 1:02 AM, Tai Lee wrote:
> > Donald,
>
> > Thanks for sharing your feedback with everyone.
>
> > I do believe that there should be some kind of validation error or at
> > least a loud warning to the console or logs when a form is bou
> The "ProfileForm({}, instance=profile)" is
> clearly passing in empty data (the empty dictionary), and it makes
> sense that Django would see the empty data, then determine that empty
> data is allowed on the fields (blank=True) and set those fields to
> empty data. If you want to avoid this, you
On Thu, Jan 12, 2012 at 7:40 PM, Tai Lee wrote:
> class Profile(models.Model):
> first_name = models.CharField(blank=True, max_length=50)
> last_name = models.CharField(blank=True, max_length=50)
> address = models.CharField(blank=True, max_length=50)
>
> class ProfileForm(ModelForm):
>
1. How does this proposal effect default values specified on model fields?
(ModelForm processing)
2. Forgive my ignorance but who has the final say if it goes in or not? And
since it should be a yes what's next?
On Thu, Jan 12, 2012 at 8:40 PM, Tai Lee wrote:
> Ian,
>
> I agree that there are a
Ian,
I agree that there are a lot of different ways that form data can be
submitted to Django, including near endless combinations of multiple
Django forms, multiple HTML forms, AJAX, etc.
If we reduce the scope of our discussion and consider only a Django
form (forgetting HTML forms and AJAX) an
On Thu, Jan 12, 2012 at 1:02 AM, Tai Lee wrote:
> Donald,
>
> Thanks for sharing your feedback with everyone.
>
> I do believe that there should be some kind of validation error or at
> least a loud warning to the console or logs when a form is bound to
> incomplete data. The only time when this
Donald
Backward compatibility can be maintained with just a log warning to give
developer time to clean up code or throwing an exception when
`settings.DEBUG=True` and only log warning when `False`; I am not sure how
this ought to be implemented but again I am big +1 for this proposal.
On Thu, Ja
Donald,
Thanks for sharing your feedback with everyone.
I do believe that there should be some kind of validation error or at
least a loud warning to the console or logs when a form is bound to
incomplete data. The only time when this should occur is for
"unsuccessful controls" such as unchecked
Tom, the problem is not caused by using `exclude`, it is caused by not
using `fields`. If you use `exclude` or simply don't specify `exclude`
or `fields` then all fields will be included. Thanks for your other
example and description of the problem, I just wanted to clarify that
it is not only a pr
Optional or required is not the same thing as important. It is
entirely valid to have important but optional fields on a model.
For example, a field that contains a string reference to a python
callback function that modifies the behaviour of some model methods
when set.
We use this on a Broadcas
I'm very much -1 on this change.
To "fix" this change would require throwing an error anytime an incomplete
dictionary was passed as the data arg to a form. This would break any existing
code that relies on this (in particular it's common practice to accept a subset
of the fields via json). So
On Wed, Jan 11, 2012 at 3:38 PM, Andre Terra wrote:
> +1 on a loud exception being raised.
>
> "Errors should never pass silently.
> Unless explicitly silenced."
>
>
> Cheers,
> AT
>
So, look at the example I (just) posted. The 'error' is that the
field-restricted form and template mistakenly don
On Wed, Jan 11, 2012 at 3:29 PM, Daniel Sokolowski
wrote:
> +1 even though I agree with what Babatunde said I support this change as
> anything that minimizes a 'gotchas' during development is very good. I
> raether get an exception instead of spending half an hour debuging why my
> data is not be
+1 on a loud exception being raised.
"Errors should never pass silently.
Unless explicitly silenced."
Cheers,
AT
On Wed, Jan 11, 2012 at 1:29 PM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:
> +1 even though I agree with what Babatunde said I support this change as
> anything t
+1 even though I agree with what Babatunde said I support this change as
anything that minimizes a 'gotchas' during development is very good. I
raether get an exception instead of spending half an hour debuging why my
data is not being saved. Sure once I figure it out I would learn to pay
attention
-1
I think a programmer should not specify a field that would contain
important data as optional in the first place. If the data loss from
not including it in the form is going to cause problems then it should
not be optional.
On 1/11/12, Tai Lee wrote:
> There is a potential for data loss with o
There is a potential for data loss with optional form fields that are
(for whatever reason) omitted from an HTML template.
For example, if we take an existing model form and template that
works, add an optional character field to the model but fail to add a
corresponding field to the HTML template
24 matches
Mail list logo
