Code

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12785 closed (wontfix)

Docs do not 'warn' against the use of auto_now and auto_now_add

Reported by: joshhunt@… Owned by: nobody
Component: Documentation Version: 1.1
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

There is nothing the the Model Field Reference documentation that warns against the use of auto_now and auto_now_add for the DateTime fields, even though they are regarded as 'hack's

This discussion http://groups.google.com/group/django-developers/browse_thread/thread/4cd631c225cb4e52/be97856ca67ede3f shows 'overwhelming core support' for dropping these all together, so perhaps there should be a warning against using them, and suggestions for what to do instead.

Attachments (0)

Change History (3)

comment:1 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

I know Jacob and Adrian (and I think Malcolm) are historically pro-nuking auto_now_add and auto_now, but we can't really suggest that people stop using auto_now and auto_add_now until there is a equally simple alternative available.

Adding CreationTimeStampField and ChangeTimeStampField has been suggested in the past, but a full discussion has never really happened, at least not formally and in public.

We're also hampered by backwards compatibility. The discussion you reference is from pre-1.0, when were still had the option of breaking APIs. We're now in a position where we need to maintain backwards compatibility, so it isn't simple to remove them.

Personally, I'm not really bothered by them. It's a really common use case, and the implementation doesn't strike me as particularly bad. I won't get bent out of shape if they go away, but I also won't be putting a lot of energy into making this change.

Marking wontfix until such time as there is some sort of consensus on the issue.

comment:2 Changed 4 years ago by Alex

For the record, this is also a dupe of a ticket I filed many a moon ago.

comment:3 Changed 4 years ago by anonymous

#7634 and #6434

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.