Re: Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?
On 16 June 2010 13:53, George Sakkis <george.sak...@gmail.com> wrote: > On Jun 16, 4:22 pm, Peter Bengtsson <pete...@gmail.com> wrote: > >> I have a modelform where I change the cleaned_data dict after I have >> run is_valid() and I'm not sure if this is the totally wrong way of >> doing things or if it's a bug. >> My code broke when I upgraded to 1.2 so it did work back in the 1.1 >> days. >> >> # models.py >> class Person(models.Model): >> name = models.CharField() >> age = models.IntegerField() >> ... >> >> # forms.py >> class PersonForm(forms.ModelForm): >> class Meta: >> model = Person >> >> # views.py >> >> form = PersonForm(data=request.POST) >> form.fields['age'].required = False >> >> if form.is_valid(): >> if not form.cleaned_data['age']: >> form.cleaned_data['age'] = >> _fetch_age_by_name(form.cleaned_data['name']) >> assert form.cleaned_data['age'] >> person = form.save() # FAILS! > > Not sure why this fails but regardless, it's not good to have part of > the validation logic outside the form. Instead define a clean() method > in the form, move there the "if not ..." part and check if it also > happens to solve the problem. > That' why I used django-developers instead of django-users. Perhaps it's a bug and not a "user error". This functionality has changed in 1.2 so it's not solid what should work how. -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com fun crosstips.org -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?
I have a modelform where I change the cleaned_data dict after I have run is_valid() and I'm not sure if this is the totally wrong way of doing things or if it's a bug. My code broke when I upgraded to 1.2 so it did work back in the 1.1 days. # models.py class Person(models.Model): name = models.CharField() age = models.IntegerField() ... # forms.py class PersonForm(forms.ModelForm): class Meta: model = Person # views.py form = PersonForm(data=request.POST) form.fields['age'].required = False if form.is_valid(): if not form.cleaned_data['age']: form.cleaned_data['age'] = _fetch_age_by_name(form.cleaned_data['name']) assert form.cleaned_data['age'] person = form.save() # FAILS! Trying to run this fails with an IntegrityError or whatever it was called because it can't save the form when the age field's valid is None even though I have corrected the form data. It smells to me like modelforminstance.save() needs to reconstruct the instance from the cleaned_data again before committing. PS. The temporary solution for other people getting stuck on this is the following: person = form.save(commit=False) person.age = form.cleaned_data['age'] person.save() -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ModelForms and ForeignKeys causing ValueError
Submitted here: http://code.djangoproject.com/ticket/13776
On Jun 14, 2:05 pm, Karen Tracey <kmtra...@gmail.com> wrote:
> On Mon, Jun 14, 2010 at 12:39 PM, Peter Bengtsson <pete...@gmail.com> wrote:
> > I'm happy to submit a ticket but wanted to check first that I'm doing
> > the right thing. I think this used to work in Django 1.1 but not now
> > in trunk.
>
> > I can better explain it with code:
>
> > [snip details]
> > The point of this is that I can make an advanced search form where the
> > form is just like the form for added one of these models. In my view I
> > never call the save() method of the form instance.
>
> > # tests.py
> > class SimpleTest(TestCase):
> > def test_model_forms(self):
> > from forms import FooBarForm
> > post = {'name':'Peter'}
> > f2 = FooBarForm(data=post)
> > self.assertTrue(not f2.is_valid())
>
> > Instead of returning False on the is_valid() function, it raises a
> > ValueError which looks like this:
>
> > [snip details]
>
> > I can understand that the field doesn't like having None set as a
> > value because it will never allow the save but I'm not interested in
> > saving here. I'm interested in getting a form that models (no pun
> > intended) itself on a model.
>
> > So, bug or feature?
>
> Looks like a bug to me. is_valid() ought not be raising a ValueError...worst
> case it should return False. But in this case True would seem to be the
> correct answer, since you've set the field to not required.
>
> Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
ModelForms and ForeignKeys causing ValueError
I'm happy to submit a ticket but wanted to check first that I'm doing
the right thing. I think this used to work in Django 1.1 but not now
in trunk.
I can better explain it with code:
# models.py
class FooBarModel(models.Model):
name = models.CharField(max_length=10)
age = models.IntegerField()
user = models.ForeignKey(User)
# forms.py
class FooBarForm(forms.ModelForm):
class Meta:
model = FooBarModel
def __init__(self, *a, **k):
super(FooBarForm, self).__init__(*a, **k)
for field in self.fields:
self.fields[field].required = False
The point of this is that I can make an advanced search form where the
form is just like the form for added one of these models. In my view I
never call the save() method of the form instance.
# tests.py
class SimpleTest(TestCase):
def test_model_forms(self):
from forms import FooBarForm
post = {'name':'Peter'}
f2 = FooBarForm(data=post)
self.assertTrue(not f2.is_valid())
Instead of returning False on the is_valid() function, it raises a
ValueError which looks like this:
Traceback (most recent call last):
File "/home/peterbe/dev/DJANGO/lc/debugapp/tests.py", line 14, in
test_model_forms
print f2.is_valid()
File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/forms.py", line 121, in is_valid
return self.is_bound and not bool(self.errors)
File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/forms.py", line 112, in
_get_errors
self.full_clean()
File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/forms.py", line 269, in full_clean
self._post_clean()
File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/models.py", line 317, in
_post_clean
self.instance = construct_instance(self, self.instance,
opts.fields, opts.exclude)
File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/forms/models.py", line 51, in
construct_instance
f.save_form_data(instance, cleaned_data[f.name])
File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/db/models/fields/__init__.py", line 416,
in save_form_data
setattr(instance, self.name, data)
File "/home/peterbe/virtualenvs/lc/lib/python2.5/site-packages/
Django-1.2.1-py2.5.egg/django/db/models/fields/related.py", line 314,
in __set__
(instance._meta.object_name, self.field.name))
ValueError: Cannot assign None: "FooBarModel.user" does not allow null
values.
I can understand that the field doesn't like having None set as a
value because it will never allow the save but I'm not interested in
saving here. I'm interested in getting a form that models (no pun
intended) itself on a model.
So, bug or feature?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Beating on an old issue; counter intuitive cascade deletes on foreign keys
Maybe the documentation is deliberately missing it because it's not supposed to have to be documented since it's supposed to just work. But as I'm suspecting, it doesn't. On 10 June 2010 02:53, Thomas Guettler <h...@tbz-pariv.de> wrote: > The documentation says django emulates "ON DELETE CASCADE": > http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects > > But it is missing how to emulate ON DELETE SET NULL. > > In this thread Kevin Howerton posted an abstract base class to emulate ON > DELETE SET NULL. But this does not work if you bulk delete with a query set. > > I opened a new ticket: > > http://code.djangoproject.com/ticket/13731 > > Thomas > > Russell Keith-Magee wrote: >> On Wed, Jun 9, 2010 at 3:53 AM, Peter Bengtsson <pe...@fry-it.com> wrote: >>> On 8 June 2010 13:09, Jeremy Dunck <jdu...@gmail.com> wrote: >>>> On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson <pete...@gmail.com> wrote: >>>>> I've now had to learn this the hard way by having real live data >>>>> deleted from my database on two production projects and it pisses me >>>>> off big time every time. >>>>> >>>>> I can accept that NOT nullable foreign relations cascade the delete >>>>> but not if they have null=True on them. Example: >>>> Actually, this looks to be fixed in 1.2. What version are you >>>> running? Closed ticket (with test cases) here: >>>> http://code.djangoproject.com/ticket/9308 >>>> >>> I'm running Django 1.2.1 so perhaps it's not fixed. >>> Sigh. I have to make a test case to prove it. >> >> Looking at Trac, #9308 was fixed in r10822, so it should be fixed in >> 1.1, and it was ported back to 1.0.X as well. >> >> We pretty clearly document that our deletion scheme emulates "ON >> DELETE CASCADE"; if you can provide evidence to the contrary, please >> open a ticket. >> >> Yours, >> Russ Magee %-) >> > > -- > Thomas Guettler, http://www.thomas-guettler.de/ > E-Mail: guettli (*) thomas-guettler + de > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com fun crosstips.org -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Beating on an old issue; counter intuitive cascade deletes on foreign keys
On 8 June 2010 13:09, Jeremy Dunck <jdu...@gmail.com> wrote: > On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson <pete...@gmail.com> wrote: >> I've now had to learn this the hard way by having real live data >> deleted from my database on two production projects and it pisses me >> off big time every time. >> >> I can accept that NOT nullable foreign relations cascade the delete >> but not if they have null=True on them. Example: > > Actually, this looks to be fixed in 1.2. What version are you > running? Closed ticket (with test cases) here: > http://code.djangoproject.com/ticket/9308 > I'm running Django 1.2.1 so perhaps it's not fixed. Sigh. I have to make a test case to prove it. > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com fun crosstips.org -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Beating on an old issue; counter intuitive cascade deletes on foreign keys
I've now had to learn this the hard way by having real live data deleted from my database on two production projects and it pisses me off big time every time. I can accept that NOT nullable foreign relations cascade the delete but not if they have null=True on them. Example: class Survey(Models): ... class Analysis(Models): survey = ForeignKey(Survey, null=True) Just looking at that it's to be fairly obvious that on deleting a Survey instance it should nullify the foreign key relation on the Analysis model. Not delete it! On a perhaps unrelated note is it a bug that I can't prevent this with signals? This doesn't work: def disconnect(sender, instance, **kwargs): for each in Analysis.objects.filter(survey=instance): each.survey = None each.save() pre_delete.connect(disconnect, sender=Survey) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Help me write tests for my patch on template rendering
Thanks for the help. Patch uploaded http://code.djangoproject.com/ticket/11421 On Oct 21, 6:49 pm, Peter Bengtsson <pete...@gmail.com> wrote: > On 21 Oct, 16:34, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:> On Wed, Oct > 21, 2009 at 9:29 AM, Peter Bengtsson <pete...@gmail.com> wrote: > > > But how do I run these? It takes many many seconds to run the whole > > > suite. > > > Seehttp://ericholscher.com/blog/2009/oct/16/easy-running-django-test-suite/ > > if you need help running the test suite. > > > Remember: `runtests.py` uses the same mechanism as Django's `manage.py > > test` does. So just like in application tests, you can limit your > > tests to just a single app using `runtests.py `, so in your > > case `runtests.py templates` will run just the template tests. > > Thanks Jacob. I didn't realise this was "an app". > On the case now! > > > Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Help me write tests for my patch on template rendering
On 21 Oct, 16:34, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Wed, Oct 21, 2009 at 9:29 AM, Peter Bengtsson <pete...@gmail.com> wrote: > > But how do I run these? It takes many many seconds to run the whole > > suite. > > Seehttp://ericholscher.com/blog/2009/oct/16/easy-running-django-test-suite/ > if you need help running the test suite. > > Remember: `runtests.py` uses the same mechanism as Django's `manage.py > test` does. So just like in application tests, you can limit your > tests to just a single app using `runtests.py `, so in your > case `runtests.py templates` will run just the template tests. > Thanks Jacob. I didn't realise this was "an app". On the case now! > Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Help me write tests for my patch on template rendering
(Sorry about the vague subject line) I've written a patch that fixes this: http://code.djangoproject.com/ticket/11421 But so far only for AttributeErrors. But I don't want to submit the patch until I've got tests for it. Can someone guide me through the jungle of Django tests to run and write a test for this? I figure the place to add test is: trunk/tests/regressiontests/templates/tests.py But how do I run these? It takes many many seconds to run the whole suite. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
