Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#21798 closed Cleanup/optimization (fixed)

Model validation should complain if both `add_now` and `auto_add_now` are specified.

Reported by: Simon Charette Owned by: anonymous
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

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.

Change History (18)

comment:1 by Tim Graham, 10 years ago

Triage Stage: UnreviewedAccepted

Accelerated deprecation sounds ok to me.

comment:2 by Russell Keith-Magee, 10 years ago

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).

comment:3 by Daniel Pyrathon, 10 years ago

Owner: changed from Simon Charette to anonymous
Status: newassigned

comment:4 by anonymous, 10 years ago

Hi,

I am working now to provide a fix for this.

Regards,
Daniel Pyrathon

comment:5 by Daniel Pyrathon, 10 years ago

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

comment:6 by Sasha Romijn, 10 years ago

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_addto a field, but 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 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?

Last edited 10 years ago by Sasha Romijn (previous) (diff)

comment:7 by Daniel Pyrathon, 10 years ago

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

comment:8 by Simon Charette, 10 years ago

@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.

Last edited 10 years ago by Simon Charette (previous) (diff)

comment:9 by Simon Charette, 10 years ago

By warn the user I mean adding a field check.

comment:10 by Daniel Pyrathon, 10 years ago

Hi charettes,

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

comment:11 by Sasha Romijn, 10 years ago

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.

comment:12 by Sasha Romijn, 10 years ago

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

  • If we also take default into account with 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.
Last edited 10 years ago by Sasha Romijn (previous) (diff)

comment:13 by pirosb3, 10 years ago

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

comment:14 by pirosb3, 10 years ago

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.

comment:15 by pirosb3, 10 years ago

Has patch: set

comment:16 by Tim Graham, 10 years ago

Easy pickings: unset
Needs documentation: unset
Needs tests: unset
Patch needs improvement: set

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.

comment:17 by Tim Graham <timograham@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In 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.

comment:18 by Russell Keith-Magee <russell@…>, 10 years ago

In 2c176eb95cc53f29367e56e0a8eec336834a299d:

Refs #21798 - Modified error number to provide room for future expansion.

Note: See TracTickets for help on using tickets.
Back to Top