I had considered designing something like this last week. It does seem to be a common requirement -- any situation where a simple field would be almost suitable but for the fact you'd like to avoid duplicates and allow fast selection of existing values. A Field shortcut could be commonly used to avoid the creation of separate models. Another example:
class Suburb(models.Model):
name = models.CharField(max_length=64, unique=True)
class Meta:
ordering = ['name']
def __unicode__(self):
return u'%s' % self.name
class School(models.Model):
name = models.CharField(max_length=64, unique=True)
class Meta:
ordering = ['name']
def __unicode__(self):
return u'%s' % self.name
class Student(models.Model):
school = models.ForeignKey(School)
suburb = models.ForeignKey(Suburb)
# ...
could be replaced with simply:
class Student(models.Model):
school = models.DictionaryField(max_length=64)
suburb = models.DictionaryField(max_length=64)
# ...
I'm not 100% sold on the name, but I think it is on the right track. I'm
also wondering whether it could be worth catering for types other than
CharField as well. For example:
team_number = models.DictionaryField(type=models.IntegerField)
This makes me wonder whether perhaps this could be generically applied to
all fields via a Field.__init__ kwarg instead:
class Student(models.Model):
school = models.CharField(max_length=64, lookup=True)
suburb = models.CharField(max_length=64, lookup=True)
team_number = models.IntegerField(lookup=True)
Either way, these fields could then be stored in separate tables
appname_modelname_fieldname, with a single field of the appropriate type
(named 'value' or similar). It would be nice to also provide external access
to these auto-generated models via something like Student.school.objects.
Currently Student.school would be a ReverseSingleRelatedObjectDescriptor,
and objects can be accessed via
Student.school.field.related.parent_model.objects.all(), but a shortcut
would be nice.
The auto-generated models could provide ordering by value, a unique
constraint on the field, and a simple __unicode__ method like the examples
above.
Simon
2010/1/17 Михаил Лукин <mihail.lu...@googlemail.com>
> Well, the simplest way is making DictionaryField more like CharField,
> except that it's values will be stored in separate table. For example
> (application name is "hardware", engine is sqlite3), if I define
>
> *class HDD(models.Model):
> form_factor = DictionaryField(max_length=10)
> capacity = models.FloatField()
> *
> there will be 2 tables generated:
>
> *CREATE TABLE "hardware_hdd_form_factor_dict" (
> "id" integer NOT NULL PRIMARY KEY,
> "form_factor" varchar(10) NOT NULL UNIQUE
> )
> CREATE TABLE "hardware_hdd" (
> "id" integer NOT NULL PRIMARY KEY,
> "form_factor_id" integer NOT NULL REFERENCES
> "hardware_hdd_form_factor_dict" ("id"),
> "capacity" real NOT NULL
> )
>
> * I guess, field constructor should not accept "unique" argument as it
> make no sense.
> I see 2 ways of rendering such field on a form:
> 1) usual <input> with autocompletion;
> 2) <select> + <input> + (maybe) radio buttons
> as it should be allowed to choose from existing and to create new
> dictionary item.
>
-- You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
