[Django] #21798: Model validation should complain if both `add_now` and `auto_add_now` are specified.

64 views
Skip to first unread message

Django

unread,
Jan 17, 2014, 10:44:23 AM1/17/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: charettes
Type: | Status: new
Cleanup/optimization | Version: master
Component: Database | Keywords:
layer (models, ORM) | Has patch: 0
Severity: Normal | Needs tests: 1
Triage Stage: | Easy pickings: 1
Unreviewed |
Needs documentation: 1 |
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
It was reported in #21785 that `add_now` and `auto_add_now` can be both
specified without triggering any kind of warning or validation or value
error.

Not sure of the path we want to take here since it should be pretty
uncommon and easily fixed by the users. Would an accelerated deprecation
be acceptable?

In order to ease the merge of the `check` framework before the 1.7 alpha
we should wait before landing a fix.

--
Ticket URL: <https://code.djangoproject.com/ticket/21798>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Jan 21, 2014, 3:43:16 PM1/21/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: charettes
Type: | Status: new
Cleanup/optimization | Version: master
Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Changes (by timo):

* stage: Unreviewed => Accepted


Comment:

Accelerated deprecation sounds ok to me.

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:1>

Django

unread,
Jan 21, 2014, 6:50:51 PM1/21/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: charettes
Type: | Status: new
Cleanup/optimization | Version: master
Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by russellm):

Check framework is now merged; although if this is deprecation path, it's
not a check framework thing - it's a DeprecationWarning where the feature
is used. The check framework only applies if we're going to make the
change and expect users to clean up the mess (as we did with the default
change on BooleanField in 1.6).

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:2>

Django

unread,
Mar 13, 2014, 6:25:36 AM3/13/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Changes (by PirosB3):

* owner: charettes => anonymous
* status: new => assigned


--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:3>

Django

unread,
Mar 13, 2014, 6:26:37 AM3/13/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by anonymous):

Hi,

I am working now to provide a fix for this.

Regards,
Daniel Pyrathon

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:4>

Django

unread,
Mar 13, 2014, 6:33:21 AM3/13/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by PirosB3):

Hi again,

I think it would be good to warn the user that both parameters cannot be
used, but also automatically make a decision for him/her (and notify it
through the warning).
Does this sound like a reasonable solution?

The warning could be: "add_now and auto_add_now cannot be both specified,
add_now has been disabled on this field"

Please let me know,
Daniel Pyrathon

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:5>

Django

unread,
Mar 13, 2014, 7:13:49 AM3/13/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by erikr):

You are talking about `auto_now` and `auto_now_add`, right? There is no
`auto_add_now`, as far as I know.

Provided that #21785 has resolved the migration issue, what is the actual
need in deprecating this? Looking at the code, I see no reason why it
should be invalid, or how it could cause issues. Yes, it would certainly
be silly to add both `auto_now` and `auto_now_add`to a field, but I there
are tons of silly field definitions that we still allow. For example, we
also allow the combination of `auto_now_add` and `default`.

A different situation would be if defining both would actually break in
some cases, like the issue we resolved in #20484. But with #21785 is
fixed, I see no similar situation here. When defining both, as far as I
know, it behaves correctly and precisely as one would expect. Therefore,
why should we disallow this combination?

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:6>

Django

unread,
Mar 13, 2014, 7:43:09 AM3/13/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by PirosB3):

Hi erikr

I just read this now, after having done my PR
(https://github.com/django/django/pull/2428)
I understand your point, but shouldn't we correct the user in any case? I
think the fields should do some validation on parameters that are mutually
exclusive.

Let me know if we would need this, in any case.

Regards,
Dan

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:7>

Django

unread,
Mar 13, 2014, 12:22:21 PM3/13/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by charettes):

@erikr, I agree that we allow many silly definition, the combination of
`auto_now_add` and `default is a good example.

However I think we should at least warn the user if two of the `add_now`,
`auto_add_now` and `default` options are defined since the defined
behavior here is ambiguous.

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:8>

Django

unread,
Mar 13, 2014, 12:50:23 PM3/13/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by charettes):

By ''warn the user'' I mean adding a field check.

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:9>

Django

unread,
Mar 13, 2014, 7:37:13 PM3/13/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by PirosB3):

Hi charettes,

so you would not take any action, other than warning the user? (you would
still keep both options enabled?)

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:10>

Django

unread,
Mar 14, 2014, 4:24:49 AM3/14/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by erikr):

Well, the decision of which option is enabled has already been made
implicitly by the code. If one sets both `auto_now_add` and `auto_now`,
the behaviour is identical to only providing `auto_now`. The warning could
indicate that. I'm sure a similar deterministic precedence is present for
`default`.

The warning could be something along the lines of (not polished): `The
combining of auto_now, auto_now_add and/or default paramaters of a ..field
is deprecated. X takes precedence over Y, which takes precedence over Z`.
Note also that there are three fields that have these parameters:
DateTimeField, DateField and TimeField, to my knowledge.

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:11>

Django

unread,
Mar 14, 2014, 4:30:32 AM3/14/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by erikr):

Eh, pressed enter too soon there. Two more notes:

* If we also take `default` into account this warning, I definitely agree
with charettes that we should fix this. Particularly as the behaviour in
combination with `default` is a lot less obvious.
* There are basically two options here: we could issue a
DeprecationWarning, and add a field check in the next version, or just add
the field check now. We went for the latter in #20484, but that was a
little more severe: that actually broke in some conditions. If I
understand comment:9 correctly, charette is in favour of adding the check
now - I don't feel strongly either way.

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:12>

Django

unread,
Mar 14, 2014, 7:37:58 AM3/14/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by pirosb3):

I think it would be more sensible to add DeprecationWarning first, and
then field check later. In makes it more smoother. But the final call is
up to you two :)
I am willing to make the changes for the choice you make. Let me know.

Dan

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:13>

Django

unread,
Mar 15, 2014, 11:43:12 AM3/15/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 0 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------

Comment (by pirosb3):

Hi

I have opted for a simple DeprecationWarning.
I also did a small amount of refactoring, to avoid duplication. Let me
know if we want me to change it.

https://github.com/django/django/pull/2428

Probably we will want to squash merge (once ready)? I have done a few
useless commits that shouldn't mess up the existing history.

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:14>

Django

unread,
Mar 15, 2014, 11:44:27 AM3/15/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 1
Keywords: | Patch needs improvement: 0
Has patch: 1 | UI/UX: 0

Needs tests: 1 |
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Changes (by pirosb3):

* has_patch: 0 => 1


--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:15>

Django

unread,
Apr 8, 2014, 2:00:01 PM4/8/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: assigned
Cleanup/optimization | Version: master

Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 0
Keywords: | Patch needs improvement: 1

Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by timo):

* needs_docs: 1 => 0
* needs_tests: 1 => 0
* easy: 1 => 0
* needs_better_patch: 0 => 1


Comment:

I think we should just add the check and forget the deprecation warning.
There are ways to ignore the check, so it wouldn't be backwards
incompatible anyway.

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:16>

Django

unread,
May 16, 2014, 6:01:35 AM5/16/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: closed
Cleanup/optimization | Version: master
Component: Database layer | Resolution: fixed

(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 0
Keywords: | Patch needs improvement: 1
Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by Tim Graham <timograham@…>):

* status: assigned => closed
* resolution: => fixed


Comment:

In [changeset:"cb15231888df2545356ad307eaea07f36aa0e8e0"]:
{{{
#!CommitTicketReference repository=""
revision="cb15231888df2545356ad307eaea07f36aa0e8e0"
Fixed #21798 -- Added check for DateTime mutually exclusive options

Added DateTimeCheckMixin to avoid the use of default, auto_now, and
auto_now_add options together. Added the fields.E151 Error that is raised
if one or more of these options are used together.
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:17>

Django

unread,
May 16, 2014, 9:41:39 AM5/16/14
to django-...@googlegroups.com
#21798: Model validation should complain if both `add_now` and `auto_add_now` are
specified.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: anonymous
Type: | Status: closed
Cleanup/optimization | Version: master

Component: Database layer | Resolution: fixed
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 0
Keywords: | Patch needs improvement: 1
Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------

Comment (by Russell Keith-Magee <russell@…>):

In [changeset:"2c176eb95cc53f29367e56e0a8eec336834a299d"]:
{{{
#!CommitTicketReference repository=""
revision="2c176eb95cc53f29367e56e0a8eec336834a299d"
Refs #21798 - Modified error number to provide room for future expansion.
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/21798#comment:18>

Reply all
Reply to author
Forward
0 new messages