Hi,
I need to use some sort of model validation in a project I am working
on and I wondered what that status of
http://code.djangoproject.com/ticket/6845 is.
Is the github code useable for production? Is there anything I can do
to help with it? Is there a recommended workaround for model
).
There is no mention of this behavior in docs.
.. (B) no model validation for decimal digits:
.full_clean() does not raise any exception:
- if the value has too many decimal digits
- or if value has too many digits
other fields, like CharField, do not validate values that
On Mon, Mar 9, 2009 at 5:25 AM, David Reynolds
wrote:
>
> Hi,
>
> I need to use some sort of model validation in a project I am working
> on and I wondered what that status of
> http://code.djangoproject.com/ticket/6845 is.
>
> Is the github code useable for production? Is
Hi,
The code on github works (tests pass) but is not ready for production
use. What you can do to help is test and mostly, write tests to help
us get there. There will be a sprint on model-validation during pycon,
which should resolve most of the outstanding issues.
Honza Král
E-Mail: honza.k
ostly, write tests to help
> us get there. There will be a sprint on model-validation during pycon,
> which should resolve most of the outstanding issues.
>
>
>
> Honza Král
> E-Mail: honza.k...@gmail.com
> ICQ#: 107471613
> Phone: +420 606 678585
>
>
>
&
I'm personally waiting for Malcolm to create the SVN branch with his
updates for continuing model validation work. However, as 1.1 freeze
is drawing near, he probably has a lot more to deal with. So, looks
that the work will be suspended until Malcolm has a free time slot for
creating the b
Hi everybody,
I have the pleasure of working on model validation (#6845) as my GSOC
project mentored by Joseph Kocherhans. I am very happy that I got the
opportunity to work on such an important part of Django as my GSOC
project.
I have already done some work on django and on the topic itself
Hi,
last week I was busy during EuroDjangoCon, so I am afraid there was
close to no progress on actual work. I did however give a talk on the
topic (see slides at [0]) and got into a few interesting discussions.
As a result of the latter I would like to reopen one design decision
that was made dur
dn't it itself be a method on the model then)?
>
> 4) How many people will actually write their own validators?
>
> By next week I should have the answer to these questions (at least my
> guesses if too few people participate) and will try and modify the
> patch to reflect th
On Wed, May 13, hcarvalhoalves wrote:
> Thanks for raising attention on this feature, I wasn't aware of your
> "Model Validation" branch and GSOC project.
>
> One question: I'm afraid of the implications of coupling validation to
> models instead of the actual
welcomed. This rounding behavior is generally superior to
ROUND_UP (what most of us are taught in gradeschool) for a number of
reasons that are inappropriate to get into here. If we're going to
round, that's the behavior we should use as default.
> .. (B) no model validation for deci
ferring to ROUND_HALF_UP, where 0.5 becomes 1?
with current ROUND_HALF_EVEN 0.5 becomes 0.
Yes I agree ROUND_HALF_EVEN in this particular situation might be
better than ROUND_HALF_UP, let's write it in docs.
.. (B) no model validation for decimal digits:
.full_clean() does not rais
ed. This rounding behavior is generally superior to
> ROUND_UP (what most of us are taught in gradeschool) for a number of
> reasons that are inappropriate to get into here. If we're going to
> round, that's the behavior we should use as default.
>
> > .. (B) no model v
On Oct 6, 2011, at 9:29 PM, Tai Lee wrote:
> Why is ROUND_HALF_EVEN superior?
ROUND_HALF_EVEN is the standard when doing financial calculations, an extremely
common use of DecimalField.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to th
x27;ROUND_HALF_DOWN', etc...
when, for instance, 'ROUND_HALF_UP' is chosen, rounding should take
place during model validation, this way after calling .full_clean()
all the instance attributes are rounded.
Code in model.clean() will already get the rounded values and
make decisions b
i am trying the save the date using formmodel but it is giving error "The
Course could not be changed because the data didn't validate."
i attched themodel.py ,form.py and view.py
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to
: +420 606 678585
On Fri, Apr 24, 2009 at 6:24 PM, Honza Král wrote:
> Hi everybody,
>
> I have the pleasure of working on model validation (#6845) as my GSOC
> project mentored by Joseph Kocherhans. I am very happy that I got the
> opportunity to work on such an important part of Dj
Hi all,
I didn't get much work done as I was waiting for feedback for
questions I posted in last week's status. I didn't get many replies
(big thanks to all that sent theirs) and it appears that the common
use case would justify going for the most powerfull interface:
def validator(value, all_val
Hello everybody,
I have been quite productive this weekend so I finally have some code
to show. I have been leveraging the hell out of git cherry-pick, git
rebase -i and various other questionable dark magic ([0]) to get my
previous work in some shape and create a nice set of commits which I
was
Hello all,
I am sorry my the gap in my reports, it kind of slipped my mind.
Currently we are in a stage where we keep moving more validation logic
into the new validator functions adding more functionality where
needed - the last example being the ability to override validator's
error messages b
Model validation is just about ready to go. I have one small issue
with it, namely with ComplexValidator, which I'll describe below, but
I think we can resolve it fairly easily. Here's a bit of background.
Sorry if you're already familiar with the branch.
Validators are functions t
permission" motto, the proposal is ideologically
based on that.
In short, db validation is shifted to `ModelForm.save()`. Outside of
ModelForms, model validation has to be done manually as
presently. The changes are less disruptive and fewer lines of
code need to be updated.
Here's the pr
Hi,
I took a great email from Gary Wilson to get me started on the status structure.
Some of the core design decisions were finalised by Jacob, Malcolm
(please scream if I have misunderstood or don't remember things
correctly) and me at DjangoCon.
Honza Král
E-Mail: [EMAIL PROTECTED]
ICQ#: 1074
Hi Aman,
This list is for discussing development of Django itself. Please post to
django-users for questions about your own applications.
On a side note, it is a bit unwieldy to attach your code files as
attachments. Please use a service like pastebin or Github's Gists to post
it online and link
There are several problems in model validation as of now. As pouring
them out here would create a too long, ill-formatted post, I created a
separate page for it at
http://wiki.github.com/mrts/honza-django/form-and-model-validation
This is just "design gruntwork", a basic text body ana
Honza,
Thanks for all your work on this -- model-validation is something
I missed when it was removed (well, moved to forms), so you have
one of my favorite GSoC projects.
> Questions for the community:
> -
> I have been toying with the idea of abstract v
Hi everybody,
I was productive right after I sent the last update but then I got
stuck on the validators. I did, however created a few test validators
and tests for those (expect the number of django tests to go up thanks
to this since I generate them semiautomatically :) ).
What I did this week
n the model. Then maybe we can add the complex
validators before the complete feature freeze?
Just some thoughts.
Cheers,
--Sean
On Fri, Jan 1, 2010 at 3:30 PM, Joseph Kocherhans wrote:
> Model validation is just about ready to go. I have one small issue
> with it, namely with Complex
On Sat, Jan 2, 2010 at 4:34 PM, Sean Bleier wrote:
>
> As for the timeline, I think that if complex validators are left as-is
> then of course it isn't a deal breaker for inclusion to trunk before
> the major feature freeze on January 5th. However, If complex
> validators need to be reworked a li
Hi everybody,
On Fri, Jan 1, 2010 at 10:30 PM, Joseph Kocherhans
wrote:
> The ComplexValidator doesn't know in advance if it's going to be used
> for model validation or form validation. ComplexValidator's get_value
> method is meant to help with this situation, but
On Sun, Jan 3, 2010 at 7:31 PM, Honza Král wrote:
> Hi everybody,
>
>
> On Fri, Jan 1, 2010 at 10:30 PM, Joseph Kocherhans
> wrote:
>
>> The ComplexValidator doesn't know in advance if it's going to be used
>> for model validation or form validation. C
On Sun, Jan 3, 2010 at 7:34 PM, Alex Gaynor wrote:
>
> What if we had some sort of wrapper class for objs, it could overide
> __getattribute__ to return either an attr if it's an obj, or a
> subscript if it's a datadict. it seems to me this would solve both
> concerns?
I was thinking along simil
On Sun, Jan 3, 2010 at 7:50 PM, Joseph Kocherhans wrote:
> On Sun, Jan 3, 2010 at 7:34 PM, Alex Gaynor wrote:
>>
>> What if we had some sort of wrapper class for objs, it could overide
>> __getattribute__ to return either an attr if it's an obj, or a
>> subscript if it's a datadict. it seems to
Malcolm had some good comments when all of this was discussed
previously:
http://groups.google.com/group/django-developers/browse_thread/thread/436307e426844ae0/f2fa0647b97569ad
He also seemed to have further ideas and code, perhaps he can be
pinged for sharing them.
Best,
MS
--
You received t
Hi Honza,
What's the story with this? Are you aiming for the 1.0 release?
On Aug 12, 8:14 pm, "Honza Král" <[EMAIL PROTECTED]> wrote:
> Hey all,
> thanks for the feedback, I am still on vacation (haven't opened my
> notebook for days, what a feeling ;) ). I will be back in a couple of
> days
Ignore me sorry i just read Jacobs comment.
What a shame, i really didn't want to be stuck with newforms
validation in 1.0
Never mind, keep up the good work :)
On Aug 18, 11:11 pm, tobydeh <[EMAIL PROTECTED]> wrote:
> Hi Honza,
>
> What's the story with this? Are you aiming for the 1.0 rele
Hi Honza, thank you for your work on model validation!
What's the status? Getting model validation in (if the powers that be
agree) would help to fix a couple of annoying bugs listed below that
are present in 1.0.
http://code.djangoproject.com/ticket/9039
http://code.djangoproject.com/t
mrts wrote:
> Looking at the path Honza has taken [1], it looks that it both
And the missing reference is
[1] http://code.djangoproject.com/ticket/6845
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develope
is conceptual: how aware should validation level be
> of storage level. Python is known for the "It's easier to ask
> forgiveness than permission" motto, the proposal is ideologically
> based on that.
>
> In short, db validation is shifted to `ModelForm.save()`. Outside of
e needs to be a clear phase prior to saving when
> you can detect validation errors so that they can be correctly presented
> back to the user. You see this already with forms where we check for
> validity and, if it's not valid, we present the errors. If it is valid,
> we move onto doi
On Oct 7, 12:08 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2008-10-06 at 15:27 -0700, mrts wrote:
> resolution on updates. The multiple simultaneous writes to the exact
> same piece of data is only one corner of the full domain space. We plan
> for the worst, but often optimise fo
On Mon, 2008-10-06 at 15:27 -0700, mrts wrote:
> On Oct 6, 2:03 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
[...]
> > The only time there's any kind of overlap is when there's a database
> > constraint such as uniqueness which we cannot guarantee will remain true
> > between the validatio
wrote:
> Hi Honza, thank you for your work on model validation!
>
> What's the status? Getting model validation in (if the powers that be
> agree) would help to fix a couple of annoying bugs listed below that
> are present in 1.0.
>
> http://code.djangoproject.com/ticket/9
On Sat, 2009-01-17 at 09:45 -0800, mrts wrote:
> There are several problems in model validation as of now. As pouring
> them out here would create a too long, ill-formatted post, I created a
> separate page for it at
>
> http://wiki.github.com/mrts/honza-django/form-and-model-vali
On Jan 18, 5:17 am, Malcolm Tredinnick
wrote:
> (b) Please do write it out and post it here so that we can have the
> discussion on the mailing list.
Let’s step back, distance ourselves from the current implementation
and look at how forms, models and modelforms should ideally
interact validatio
As I understand it, this is primarily about avoiding duplicate
validation of some pieces of data when it's not necessary, right? So
it's really only applicable to the ModelForm case?
This is a pretty good summary of the situation, although I suspect
there's a fairly easy solution at hand, which I
On Mon, Jan 19, 2009 at 4:17 PM, mrts wrote:
> And now something completely different
> ==
>
> "Every problem in computer science can be solved by
> another level of indirection."
- David Wheeler
" ... except the problem of too many levels of indirection"
-
On Monday 19 Jan 2009 6:52:15 pm Rajeev J Sebastian wrote:
> On Mon, Jan 19, 2009 at 4:17 PM, mrts wrote:
> > And now something completely different
> > ==
> >
> > "Every problem in computer science can be solved by
> > another level of indirection."
>
> - Dav
On Jan 19, 1:43 pm, Malcolm Tredinnick
wrote:
> one. Short version: when the form field validation would match what the
> model field is going to do anyway, don't do anything at the form level.
> The model field validation is about to be called anyway.
[snip]
> The solution here might not be to
On Jan 19, 11:23 pm, mrts wrote:
> The directory-based approach is best, I'll go with it -- but it's yet
> uncertain
> when as I have to handle pressing matters at work during daytime.
I've implemented some fundamental changes that need review. The commit
is at
http://github.com/mrts/honza-djan
On Thu, 2009-01-22 at 17:27 -0800, mrts wrote:
[]
> A
> side note: the `instance` attribute is not used in validator functions
> and I can't see a clear use case for it, so it looks like it can be
> removed -- prove me wrong please (I do see obscure corner cases where
> it could be useful --
On Jan 23, 3:40 am, Malcolm Tredinnick
wrote:
> On Thu, 2009-01-22 at 17:27 -0800, mrts wrote:
>
> []
>
> > A
> > side note: the `instance` attribute is not used in validator functions
> > and I can't see a clear use case for it, so it looks like it can be
> > removed -- prove me wrong pleas
I should be around during the weekend so I will give it a try as well...
Honza Král
E-Mail: honza.k...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
On Fri, Jan 23, 2009 at 2:56 AM, mrts wrote:
>
> On Jan 23, 3:40 am, Malcolm Tredinnick
> wrote:
>> On Thu, 2009-01-22 at 17:27 -0800, mr
As the uniform all values approach has created a bit of confusion, let
me present a larger example:
Validators in core.validators should not be concerned with either
model or form internals if possible. This is currently straightforward
to achieve by passing all values always as a dict via
form.c
I haven't been following everything, but I do have a couple comments
to make here.
On Fri, Jan 23, 2009 at 8:04 AM, mrts wrote:
> works both for forms and models with the proposed approach (all_values
> is model_instance.__dict__.copy() in model field validation case).
One thing to consider is
After discussing with Honza, we agreed that the dichotomy between
forms and models that was present before will remain, i.e. instance
will always be a model instance if given and all_values will always be
form.cleaned_data.
Honza's rationale was that it's common to have properties in models
and t
On Jan 23, 4:38 pm, Marty Alchin wrote:
> I haven't been following everything, but I do have a couple comments
> to make here.
Thanks, interesting points. The get_value approach looks simpler
though, so unless you or anybody else disagrees I'll implement this.
--~--~-~--~~---
After several discussions with Honza, we are still on somewhat
different positions what the validator function signature should
be and how core validators should access the fields of a form or
a model instance.
In core validators, no special case handling of forms and models
is needed even in mul
On Sat, 2009-01-24 at 14:13 -0800, mrts wrote:
> After several discussions with Honza, we are still on somewhat
> different positions what the validator function signature should
> be and how core validators should access the fields of a form or
> a model instance.
The second bit is relatively mi
The last unsolved model-validation design issue is the error message
protocol (my work on fields is waiting on it). Let me present the
approach that looks sane to me.
The old Field.default_error_messages dict and corresponding
logic is no longer required (and removed in my branch) as default
On Feb 18, 2:28 pm, mrts wrote:
> def validate(self, value, all_values={}, form_instance=None):
That should have been
def validate(self, value, all_values={}):
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Hi,
see inline text.
On Wed, Feb 18, 2009 at 1:28 PM, mrts wrote:
>
> The last unsolved model-validation design issue is the error message
> protocol (my work on fields is waiting on it). Let me present the
> approach that looks sane to me.
>
> The old Field.default_error
On Feb 18, 8:03 pm, Honza Král wrote:
> Hi,
> see inline text.
>
> On Wed, Feb 18, 2009 at 1:28 PM, mrts wrote:
>
> > The last unsolved model-validation design issue is the error message
> > protocol (my work on fields is waiting on it). Let me present the
> &g
On Wed, 2009-02-18 at 04:28 -0800, mrts wrote:
> The last unsolved model-validation design issue is the error message
> protocol (my work on fields is waiting on it).
Well, it's the the last issue, but it's certainly a stumbling block.
I've been spending quite a lot of
On Feb 19, 12:49 am, Malcolm Tredinnick
wrote:
> On Wed, 2009-02-18 at 04:28 -0800, mrts wrote:
> > The old Field.default_error_messages dict and corresponding
> > logic is no longer required (and removed in my branch) as default
> > error messages live in core/validators now.
>
> It *is* still r
Hi,
the model validation layer checks for uniqueness of the primary_key
(in base.py: _perform_unique_checks()). But what if the pk value is
None (indicating for an AutoField that it should get an id from the
DB)?
Currently, it still issues a DB query testing if there's an entity
with a pk of
I just committed r12206 [1] which contains a few
backwards-incompatible changes to model validation. First off,
ModelForm used to validate your entire model and raise
UnresolvableValidationError for any model fields that had errors, but
were excluded from the form. Now, ModelForm will only
Strong 1+
It doesn't seem that the core team is interested in working on Model
validation at the moment: http://code.djangoproject.com/ticket/13121
(my failed ticket)
The current thinking by the powers that be is that you cannot
introduce model-level validation enforcement without breakin
On Tue, Mar 16, 2010 at 10:36 AM, orokusaki wrote:
> It doesn't seem that the core team is interested in working on Model
> validation at the moment: http://code.djangoproject.com/ticket/13121
> (my failed ticket)
Stop right there and actually go back and *read* all the feedback
t doesn't seem that the core team is interested in working on Model
> > validation at the moment:http://code.djangoproject.com/ticket/13121
> > (my failed ticket)
>
> Stop right there and actually go back and *read* all the feedback
> you've gotten, because right now
On Mar 16, 10:12 am, James Bennett wrote:
> On Tue, Mar 16, 2010 at 10:36 AM, orokusaki wrote:
> > It doesn't seem that the core team is interested in working on Model
> > validation at the moment:http://code.djangoproject.com/ticket/13121
> > (my failed ticket
On Mar 16, 10:16 am, Harro wrote:
> Just my brainfart when looking at this: Can't you simply add a pre
> save signal to call the full clean method?
>
> Dunno if that will work or not, just the first thing I would try.
>
> On Mar 16, 5:12 pm, James Bennett wrote:
>
Hey James, I've not used sign
On Wed, Mar 17, 2010 at 1:00 AM, orokusaki wrote:
> Actually I'm not lying. Russell hasn't given me any feedback regarding
> my idea or patch. I didn't simply reopen tickets. Russell changed my
> ticket to a documentation ticket, so I opened a new ticket to discuss
> that which he avoided in his d
On Thu, Jan 21, 2010 at 1:28 PM, Gerry wrote:
> without using ModelForms? I really like the new Model validation but I
> don't
> like (nor think its very DRY) to override the save method for all of
> my models
> to just call full_clean(). It would be nice if there was some
Thanks James,
I'll focus on this here and see what I can come up with.
Michael
--
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
Came across this issue that was introduced with model validation:
http://code.djangoproject.com/ticket/14102
Would love a review.
Travis
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djan
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
On Sat, Jan 9, 2010 at 8:52 AM, Waldemar Kornewald wrote:
> Hi,
> the model validation layer checks for uniqueness of the primary_key
> (in base.py: _perform_unique_checks()). But what if the pk value is
> None (indicating for an AutoField that it should get an id from the
> DB)
> Sorry for the problems, folks.
Hey, no worries, thanks for the good work. Seems like a very usable
solution.
--
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 unsu
/instances/#validating-objects
I opened a ticket at http://code.djangoproject.com/ticket/12586
Johann
Joseph Kocherhans wrote:
I just committed r12206 [1] which contains a few
backwards-incompatible changes to model validation. First off,
ModelForm used to validate your entire model and raise
Hello folks,
I reported an issue with runserver on the django trac [1], and aaugustin
asked that I seek feedback here on the list.
In short, the problem I am having is that exceptions thrown during model
validation will cause runserver to abort. This might seem like a
reasonable outcome, but
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 valida
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
> wrote:
>> A cou
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,
>
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
> wrot
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 ValidationErr
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 ModelForm.save() would automati
be a context manager that does form validation and
> form.save(commit=False) on enter + model validation and save() on exit. Of
> course this will only work on Python 2.5+, so it's probably no good for
> django 1.2. Just wanted to share an idea.
FTR, this is a pretty neat idea.
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 = form.save(commit=False)
p.user = request.user
>
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", "answer":"bar"} )
> if form.is_valid():
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( {"secret_question":"foo", "answer":"bar"} )
> if form.is_valid():
>
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 Model.save doesn't do valid
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
> wrote:
>> ...
>> form = SecretQuestionForm( {"secre
having model objects returned by ModelForm.save
(commit=False) automatically trigger model validation when model.save
() is called, even if model.save() does not normally trigger model
validation?
Cheers.
Tai.
--
You received this message because you are subscribed to the Google Groups
"D
t__), even
with a partial form, do you expect model.full_validate being called?
2) Are you OK with ripping save(commit=False) functionality to some
other method? (current functionality can stay with a deprecation
warning for example)
3) Would you want errors raised in model validation after i
2) Are you OK with ripping save(commit=False) functionality to some
> other method? (current functionality can stay with a deprecation
> warning for example)
>
> 3) Would you want errors raised in model validation after it being
> created by a form (commit=False) to appear on the form?
rent functionality can stay with a deprecation
> warning for example)
I wouldn't like to see that idiom changed. We can create another attr
on the form but leave is_valid()?
> 3) Would you want errors raised in model validation after it being
> created by a form (commit=False) to appe
)
No.
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 do stuff to it". If Django goes ahead and does
imp
o I can do stuff to it". If Django goes ahead and does
> implicit model validation there and raises an exception, it's just
> telling me what I already knew: the object's not ready to be saved.
> But now I get to do extra work to catch the exception, and that's bad
>
;t think this object is ready to be saved yet, but I need
>> the object so I can do stuff to it". If Django goes ahead and does
>> implicit model validation there and raises an exception, it's just
>> telling me what I already knew: the object's not ready to be saved.
&
1 - 100 of 134 matches
Mail list logo
