Opened 16 years ago
Closed 12 years ago
#10134 closed Uncategorized (fixed)
unique_for_* broken?
Reported by: | Walter Doekes | Owned by: | Alex Gaynor |
---|---|---|---|
Component: | Forms | Version: | 1.4 |
Severity: | Normal | Keywords: | unique_for_date unique_for_month unique_for_year |
Cc: | zerok@…, flosch@…, Marek Onuszko | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
I was looking for the unique_for_date (et al.) implementation to re-use some of it for my own purposes, but I can't seem to find it.
On these pages, I read that one can do the following:
http://docs.djangoproject.com/en/dev/ref/models/fields/#unique-for-date
class Test(models.Model): unique_for_date = models.CharField(max_length=128, unique_for_date='date') date = models.DateField()
If I read it correctly, it means that when using the admin form (admin.site.register(Test)), I shouldn't be able to enter the same value for unique_for_date
for the same date. But instead, the admin form does no uniqueness checking at all.
In [8616] I see that a lot of code that touches the unique_for_* is removed, but I don't see it get added in another place.
Am I missing something?
Attachments (4)
Change History (21)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Karen you're right about this, I'll add it to the model-validation wiki and bring it up with Honza this evening if he's on.
comment:3 by , 16 years ago
milestone: | → 1.1 |
---|---|
Triage Stage: | Unreviewed → Accepted |
I think we need a similar stop-gap to unique_together for unique_for_date in 1.1.
comment:4 by , 16 years ago
Cc: | added |
---|
comment:5 by , 16 years ago
Cc: | added |
---|
comment:6 by , 16 years ago
Owner: | changed from | to
---|
comment:7 by , 16 years ago
Component: | Database layer (models, ORM) → Forms |
---|
Model Validaiton isn't making it in for 1.1 so this is just going to be solved in forms.
by , 16 years ago
Attachment: | unique_for_stuff.diff added |
---|
by , 16 years ago
Attachment: | unique_for_stuff.2.diff added |
---|
by , 16 years ago
Attachment: | unique_for_stuff.3.diff added |
---|
comment:8 by , 16 years ago
That comment was supposed to say, "long function is no longer long" so as to be witty, now I just sound like an idiot :/
comment:9 by , 16 years ago
Has patch: | set |
---|
comment:10 by , 16 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:11 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:12 by , 16 years ago
comment:16 by , 12 years ago
Cc: | added |
---|---|
Easy pickings: | unset |
Patch needs improvement: | set |
Resolution: | fixed |
Severity: | → Normal |
Status: | closed → new |
Type: | → Uncategorized |
UI/UX: | unset |
Version: | master → 1.4 |
I stumbled upon the same problem. I'm using Python 2.7.3 and Django 1.4.5-1 from Debian repositories. I can add multiple entries with identical values and the admin interface doesn't complain. I tried with both 'slug' and 'title'.
# models.py from django.db import models from django.utils.timezone import now as utcnow now = utcnow() # replacing - date.now() causes problems with auto_now_add class Entry(models.Model): created_at = models.DateTimeField(default=now, editable=False) title = models.CharField(max_length = 50) content = models.TextField() slug = models.SlugField(unique_for_date='created_at') def __unicode__(self): return self.title class Meta: ordering = ['-created_at'] # admin.py from news.models import Entry from django.contrib import admin class EntryAdmin(admin.ModelAdmin): prepopulated_fields = {'slug': ('title',)} list_filter = ['created_at'] date_hierarchy = 'created_at' admin.site.register(Entry, EntryAdmin)
comment:17 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Please do not reopen bugs fixed 4 years ago. Create a new ticket where you can reference this one, thanks.
This would be one of the things lost in the move from the old forms/manipulators structure to new forms. The implementation/enforcement of the parameter was removed, but not the ability to specify it, since (I believe) the intent was for the check to only be MIA for as long as model validation (#6845) was missing. Model validation was hoped to be included in 1.0, but unfortunately it is still not in trunk.
Furthermore, from what I can glean of the current implementation at http://github.com/HonzaKral/django/tree/model-validation the check for these parameters is not yet handled by model validation, either, so I'm going to leave this open rather than closing it as a dup of #6845. From what I can tell restoration of checks for parameters like this is not currently covered by #6845, nor do I see it on any of the open issues/todo type pages, so this ticket can serve as a tracker for restoring this function which seems to have slipped through the cracks somewhere. (For anyone more up-to-speed on model validation, if I'm wrong about this bit being missing, or for that matter if I'm wrong about this function intending to be re-supported via model validation, feel free to correct me.)