> We have several accepted tickets regarding developer headaches when a
>> blank=True field, which skips model validation by design[1], contains
>> inappropriate empty values (e.g. None for a not-nullable field or the empty
>> string where empty strings aren't allowed). I
; blank=True field, which skips model validation by design[1], contains
> inappropriate empty values (e.g. None for a not-nullable field or the empty
> string where empty strings aren't allowed). I want to see what the
> community thinks is reasonable here and move them to a resolutio
OK, super.
Would you then fancy looking at that docs change? It does come up. It _is_
surprising that `blank` has this effect, and I'm not convinced it says
clearly anywhere how you should approach it…
Thanks for your efforts digging into this! 👍
C.
On Tuesday, 27 July 2021 at 14:22:50 UTC+2
This makes good sense, Carlton, and I didn't mean to be rushing your reply!
"That way lies madness" is entirely correct. Just wanted to map the terrain
after I had so confidently commented on one Trac ticket about wontfix-ing
it, since on it there were various opinions about possible courses of
Hi Jacob.
Thanks for the follow-up. Good hustle! 😉
I saw your comments on Trac last week, and was preparing a response.
The trouble with these 8, 7, and 5 year old tickets is that they're tricky…
Let me put the take-home first, I think that in-themselves we should close
all
three of these t
Hi group,
We have several accepted tickets regarding developer headaches when a
blank=True field, which skips model validation by design[1], contains
inappropriate empty values (e.g. None for a not-nullable field or the empty
string where empty strings aren't allowed). I want to see
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 cust
> 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
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 I
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,
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
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 error
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
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
ll the same for your reply -- better late than never.
Why? If you know it's not really a problem, why don't you want it silenced?
> I understand that (as you mention on the ticket) you don't want to turn
> off
> model validation -- I imagine there are plenty of othe
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 as I discovered, there e
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
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
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
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
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
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
).
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
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
On Mon, 2010-04-19 at 15:44 -0500, Richard Laager wrote:
> In the end, *my* requirement is that I have *some place* to put
> validation code that 1) can see the whole model instance, 2) will be run
> from the admin interface, and 3) will return nice validation failures to
> the user (not throw exce
hy?
> B) If not, how can I implement this such that it will get accepted?
>
> I'd like to have it in for 1.2 if possible, as the model validation
> interfaces are new. Once released, there will be more
> backwards-compatibility guarantees to maintain.
>
>
>
>
>
&g
).
A) Is this an unreasonable pony? If so, why?
B) If not, how can I implement this such that it will get accepted?
I'd like to have it in for 1.2 if possible, as the model validation
interfaces are new. Once released, there will be more
backwards-compatibility guarantees to maintain.
On Mon,
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
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
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 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 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
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 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
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
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!
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 one care to
> say at least 'ok
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
regressions.
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. | +
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 |
(___) |
/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
> 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
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
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 issues please
; >> 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
> > >> implicit
sically 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
> >> implicit model validation there and raises an exception, it's just
> >>
-Original Message-
From: Ivan Sagalaev
Date: Sun, 10 Jan 2010 03:25:29
To:
Subject: Re: Model validation incompatibility with existing Django idioms
Joseph Kocherhans wrote:
> # Run validation that was missed by the form.
> p.validate_fields(fields=
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', 'primary_contact'])
>> p.val
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
p.full_validate(fields=['u
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
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
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
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)
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
ould 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 form without *fully* validating a
model. But for a bit different reason that I didn't see
int may exist at the database level
that Python doesn't know about (or may not be able to enforce efficiently).
I regret and apologize that I'm arriving to this thread rather late. Is
there a document somewhere that discusses, or could someone describe, how
model validation fits betw
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 wasn't, however, proposin
;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.
&
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
>
)
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
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
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?
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
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
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
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 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, 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 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
>
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 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
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 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
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,
>
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
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
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
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
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
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: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
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 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
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
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
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
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
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
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
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
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
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
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
: +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 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
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
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
>
>
>
&
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
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,
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
1 - 100 of 134 matches
Mail list logo
