#12785 closed (wontfix)
Docs do not 'warn' against the use of auto_now and auto_now_add
Reported by: | 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: | no | UI/UX: | no |
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.
Change History (3)
comment:1 by , 15 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 15 years ago
For the record, this is also a dupe of a ticket I filed many a moon ago.
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.