Re: Model validation incompatibility with existing Django idioms

Joseph Kocherhans wrote: > Ok. I see it. ;) :D > Sorry, I've been out of town for a while with no > internet access. 12577 is near the top of my list to look at. ok thanks :D -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for!

Re: Model validation incompatibility with existing Django idioms

On Tue, Jan 19, 2010 at 1:04 AM, Raffaele Salmaso wrote: > Raffaele Salmaso wrote: >> Joseph Kocherhans wrote: >>> regressions? >> http://code.djangoproject.com/ticket/12577 > Hello, is anybody out there? > Sorry if I seem rude, but there is a severe regression an no

Re: Model validation incompatibility with existing Django idioms

Raffaele Salmaso wrote: > Joseph Kocherhans wrote: >> regressions? > http://code.djangoproject.com/ticket/12577 Hello, is anybody out there? Sorry if I seem rude, but there is a severe regression an no one care to say at least 'ok I see it', even when there is an *explicit* request for

Re: Model validation incompatibility with existing Django idioms

Raffaele Salmaso wrote: > Joseph Kocherhans wrote: >> regressions? > http://code.djangoproject.com/ticket/12577 Ok, BaseGenericInlineFormSet doesn't have save_new to save the generic fk.pk Reenabled and everything go as before. -- ()_() | That said, I didn't actually _test_ my patch. |

Re: Model validation incompatibility with existing Django idioms

Joseph Kocherhans wrote: > regressions? http://code.djangoproject.com/ticket/12577 -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) |

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > A couple of related tickets filed today about model validation: > > http://code.djangoproject.com/ticket/12513 > http://code.djangoproject.com/ticket/12521 This has been fixed in r12206 [1]. Could people who had

Re: Model validation incompatibility with existing Django idioms

2010/1/10 Tai Lee > On Jan 9, 12:36 am, Honza Král wrote: > > On Fri, Jan 8, 2010 at 11:59 AM, koenb > wrote: > > > > > On 8 jan, 10:03, James Bennett wrote: > > > > >> Suppose I have a

Re: Model validation incompatibility with existing Django idioms

On Jan 9, 12:36 am, Honza Král wrote: > On Fri, Jan 8, 2010 at 11:59 AM, koenb wrote: > > > On 8 jan, 10:03, James Bennett wrote: > > >> Suppose I have a ModelForm and call save(commit=False) to get the > >> instance so

Re: Model validation incompatibility with existing Django idioms

-Original Message- From: Ivan Sagalaev <man...@softwaremaniacs.org> Date: Sun, 10 Jan 2010 03:25:29 To: <django-developers@googlegroups.com> Subject: Re: Model validation incompatibility with existing Django idioms Joseph Kocherhans wrote: > # Run validation

Re: Model validation incompatibility with existing Django idioms

On Sat, Jan 9, 2010 at 6:25 PM, Ivan Sagalaev wrote: > Joseph Kocherhans wrote: >> >>            # Run validation that was missed by the form. >>            p.validate_fields(fields=['user', 'primary_contact']) >>            p.validate_unique(fields=['user',

Re: Model validation incompatibility with existing Django idioms

Joseph Kocherhans wrote: # Run validation that was missed by the form. p.validate_fields(fields=['user', 'primary_contact']) p.validate_unique(fields=['user', 'primary_contact']) p.validate() Can this be shortcut to

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > A couple of related tickets filed today about model validation: > > http://code.djangoproject.com/ticket/12513 > http://code.djangoproject.com/ticket/12521 > > The first one describes the issue best - the new model

Re: Model validation incompatibility with existing Django idioms

On Sat, Jan 9, 2010 at 7:46 AM, Ivan Sagalaev wrote: > I too would opt for an implementation that makes model validation optional, >> i.e., a call that developers must explicitly make, if they choose, before >> saving a model. >> > > I'm +1 on some way of validating a

Re: Model validation incompatibility with existing Django idioms

Tobias McNulty wrote: I don't see why model validation should be bound up with forms at all. I'm not the one who designed it, so it's just me view. I think this is just useful: if you have a code validating, say, a CharField at the model level why not reuse it at the form level? What's

Re: Model validation incompatibility with existing Django idioms

Tobias McNulty wrote: I regret and apologize that I'm arriving to this thread rather late. To support the tradition, I'm apoligizing for this too :-). Though it's funny how everyone thinks they're "late" on a couple-of-days-old thread :-). Anyway... I too would opt for an implementation

Re: Model validation incompatibility with existing Django idioms

On Fri, Jan 8, 2010 at 4:03 AM, James Bennett wrote: > On Thu, Jan 7, 2010 at 10:40 AM, Honza Král wrote: > > ModelForm has a save() method that saves the model. It is reasonable > > to assume that if the form is valid, the save() method call should

Re: Model validation incompatibility with existing Django idioms

On Fri, Jan 8, 2010 at 8:36 AM, Honza Král wrote: > I just hate the name save(commit=False) when it has nothing to do with > saving or committing, it just DOESN'T call save, it's imho misleading. > I understand why that is and how it came to be, I just don't like it. > I

Re: Model validation incompatibility with existing Django idioms

On Fri, Jan 8, 2010 at 11:59 AM, koenb wrote: > > > On 8 jan, 10:03, James Bennett wrote: > >> Suppose I have a ModelForm and call save(commit=False) to get the >> instance so I can do some more work on it. I'm basically saying to >> Django "I

Re: Model validation incompatibility with existing Django idioms

On 8 jan, 10:03, James Bennett wrote: > Suppose I have a ModelForm and call save(commit=False) to get the > instance so I can do some more work on it. I'm basically saying to > Django "I don't think this object is ready to be saved yet, but I need > the object so I can

Re: Model validation incompatibility with existing Django idioms

On Thu, Jan 7, 2010 at 10:40 AM, Honza Král wrote: > ModelForm has a save() method that saves the model. It is reasonable > to assume that if the form is valid, the save() method call should > succeed, that's why the entire model is validated. Actually, I can see a strong

Re: Model validation incompatibility with existing Django idioms

> ModelForm has a save() method that saves the model. It is reasonable > to assume that if the form is valid, the save() method call should > succeed, that's why the entire model is validated. mf.is_valid() I have understood as validation strictly on the included fields in the form. I abuse this

Re: Model validation incompatibility with existing Django idioms

For us we definitely use this behavior, and I'm guessing this is about to bite us in the ass. I would think a simple fix would be to have a commit=False, and validate=True keyword arg. By default, validate is NoInput, but if commit is False it defaults to False. Wouldn't that be a simple enough

Re: Model validation incompatibility with existing Django idioms

Hi everybody, sorry for the late reply, was busy. Just to add few points that lead us to do it this way: ModelForm has a save() method that saves the model. It is reasonable to assume that if the form is valid, the save() method call should succeed, that's why the entire model is validated. We

Re: Model validation incompatibility with existing Django idioms

It makes sense to me that the developer should first check that their form is valid and second check that their model object is valid when calling ModelForm.save(commit=False). This could be done by having the developer check the result of model.full_validate() before calling model.save(), or by

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 2010, at 3:59 PM, Joseph Kocherhans wrote: > On Wed, Jan 6, 2010 at 4:46 PM, Jeremy Dunck wrote: >> On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans >> wrote: >> ... > On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 3:57 pm, Brian Rosner wrote: > Yeah, I think that must have been a typo in Joseph's mail. The way I read it > that the model knows what fields it has already validated and the call to a > Model.save would validate the rest. Actually, I just realized that

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 4:46 PM, Jeremy Dunck wrote: > On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans > wrote: > ... On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > ... > form = SecretQuestionForm(

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 2010, at 3:46 PM, Jeremy Dunck wrote: > On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans > wrote: > ... On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > ... > form = SecretQuestionForm( {"secret_question":"foo",

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans wrote: ... >>> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison >>> wrote: ... form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} ) if form.is_valid():    p =

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 2010, at 2:48 PM, Łukasz Rekucki wrote: > Maybe you could do something like this: > > with form.valid_model() as model: # i'm not good at inventing names > model.user = request.user > model.primary_contact = somecontact > > The valid_model() would be a context manager that

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 4:06 PM, Brian Rosner wrote: > > On Jan 6, 2010, at 2:56 PM, Joseph Kocherhans wrote: >> I had another idea that I think might work out. What if >> ModelForm.validate() only validated fields on the form, like it worked >> before the merge, and

Re: Model validation incompatibility with existing Django idioms

On Jan 6, 2010, at 2:56 PM, Joseph Kocherhans wrote: > I had another idea that I think might work out. What if > ModelForm.validate() only validated fields on the form, like it worked > before the merge, and ModelForm.save() would automatically validate > the excluded fields, raising

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 3:26 PM, Waylan Limberg wrote: > I've only scanned the docs the other day and haven't actually used the > new model validation stuff, so my impressions may be a little off, > but... > > On Wed, Jan 6, 2010 at 2:54 PM, Joseph Kocherhans

Re: Model validation incompatibility with existing Django idioms

First time posting here, so please excuse me if my opinions aren't very useful and my bad English. 2010/1/6 Waylan Limberg > I've only scanned the docs the other day and haven't actually used the > new model validation stuff, so my impressions may be a little off, > but... > >

Re: Model validation incompatibility with existing Django idioms

I've only scanned the docs the other day and haven't actually used the new model validation stuff, so my impressions may be a little off, but... On Wed, Jan 6, 2010 at 2:54 PM, Joseph Kocherhans wrote: > On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison

Re: Model validation incompatibility with existing Django idioms

On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison wrote: > A couple of related tickets filed today about model validation: > > http://code.djangoproject.com/ticket/12513 > http://code.djangoproject.com/ticket/12521 > > The first one describes the issue best - the new model

Model validation incompatibility with existing Django idioms

A couple of related tickets filed today about model validation: http://code.djangoproject.com/ticket/12513 http://code.djangoproject.com/ticket/12521 The first one describes the issue best - the new model validation code breaks the following common Django convention: form = SecretQuestionForm(