Re: Suggestion: DictionaryField
Hi, I must correct my post. When I used "default" option I mean "choices" option. On 18 led, 22:23, Михаил Лукинwrote: > There is no need in ENUM functionality since 'choices=' option exists. I must disagree with you. It looks like choices emulate ENUM but it's not true. What's not supported: - model validating: no other values except that in choices are valid - support for binary representation of values and binary matching in ORM queries For SETs there's another condition: - unique values in SETs Vaclav > Representing ENUM and SET as input fields even with autocompletion may be > confusing in multi-language applications. -- 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.
Re: Suggestion: DictionaryField
Hi, for me it has a big WTF factor. Automatically created tables according to field. As DirectoryField I would suppose behaviour like SET or ENUM fields in MySQL. I hope there are equivalents in other DB storages. Implementation of this types I would appreciate in Django ORM. This doesn't need to be even new field. It will be sufficient to have implemented those use cases for present field types which gets default values as dictionary or tuple of tuples. - validating: no other values except set in defaults are valid - unique values in SETs - support for binary representation of values and binary matching in ORM queries Vaclav On 17 led, 00:02, Mihail Lukinwrote: > Hi, Community > > Sometimes an application model include a lot of fields which are just > dictionary values. Example: > > class HDD(models.Model): > form_factor = models.ForeignKey(HDDFF) > capacity = models.ForeignKey(HDDCap) > interface = models.ForeignKey(HDDIntf) > ... > > and so on, where HDDFF, HDDCap and HDDIntf are similar classes. > Abstract class with only one field "name" may be used, so that this > classes could be defined like this: > > class HDDFF(DictModel): pass > > but it is not as good as something like this: > > class HDD(models.Model): > form_factor = models.DictionaryField() > capacity = models.DictionaryField() > interface = models.DictionaryField() > > Database tables "hdd_form_factor_dict", "hdd_capacity_dict" and so on > could be created automatically, just like it is done by > ManyToManyField. > > What do you think about that? -- 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.
Re: Suggestion: DictionaryField
Mihail's initial version doesn't have any data in each model. So presumably he's just tracking primary keys. In which case a PositiveIntegerField would work. And some of the use cases look awfully like 'choices=...' would be the best bet. Others would be fine if you queried the current set of values and put them in a drop down on the form: options = set(MyModel.objects.values_list('opt', flat=True)) But I have had the odd occassion where I've wanted a set of options (a la choices) but that were editable from the admin. Because of the need to edit them, however, they have to be top level manually created models, otherwise I can't specify their admin interface and edit them. Ian. On Jan 18, 3:35 am, Yuri Baburovwrote: > Hi Łukasz, Mikhail, > > You can go further and create DictionaryField. > > But I see the problems you will get with it: > 1) You won't be able to refer to the model afterwards, since it's not > defined in models.py as global. > 2) I prefer to make DictionaryModel key the primary_key when > appropriate, you'll need that option. > 3) Additional fields or methods can appear at any time later, making > such "economy" almost useless. > > So, my only wish is better builtin autocomplete widget for admin and > regular usage. > Current default one (for raw_id_fields) looks overcomplicated. > Unfortunately, The Right autocomplete widget for django admin doesn't exist > yet. > > 2010/1/18 Łukasz Rekucki : > > > > > 2010/1/17 Simon Meers : > >> 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. > > > This seems like a lot of work and tweeks, just so you can save that 2 > > lines to define a class. > > > class DictModel(models.Model): > > class Meta: > > abstract = True > > ordering = ['value'] > > unique_together = ('value',) > > > def __unicode__(self): > > return unicode(self.value) > > > # just 2 lines per dictionary and you have all the flexibility you'll ever > > need > > class School(DictModel): > > value = models.CharField(max_length=64) > > > class Suburb(DictModel): > > value = models.IntegerField() > > > Also, by giving your dictionaries an explicit name, they can be easily > > reused. I would probably also make the "value" field a primary_key, so > > that you won't have to make all those joins just to print out > > student's info. > > >> Simon > > >> 2010/1/17 Михаил Лукин > > >>>
Re: Suggestion: DictionaryField
Hi Łukasz, Mikhail, You can go further and create DictionaryField. But I see the problems you will get with it: 1) You won't be able to refer to the model afterwards, since it's not defined in models.py as global. 2) I prefer to make DictionaryModel key the primary_key when appropriate, you'll need that option. 3) Additional fields or methods can appear at any time later, making such "economy" almost useless. So, my only wish is better builtin autocomplete widget for admin and regular usage. Current default one (for raw_id_fields) looks overcomplicated. Unfortunately, The Right autocomplete widget for django admin doesn't exist yet. 2010/1/18 Łukasz Rekucki: > 2010/1/17 Simon Meers : >> 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. > > This seems like a lot of work and tweeks, just so you can save that 2 > lines to define a class. > > class DictModel(models.Model): > class Meta: > abstract = True > ordering = ['value'] > unique_together = ('value',) > > def __unicode__(self): > return unicode(self.value) > > # just 2 lines per dictionary and you have all the flexibility you'll ever > need > class School(DictModel): > value = models.CharField(max_length=64) > > class Suburb(DictModel): > value = models.IntegerField() > > Also, by giving your dictionaries an explicit name, they can be easily > reused. I would probably also make the "value" field a primary_key, so > that you won't have to make all those joins just to print out > student's info. > >> >> Simon >> >> >> 2010/1/17 Михаил Лукин >>> >>> 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 with
Re: Suggestion: DictionaryField
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 Михаил Лукин> 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 with autocompletion; > 2) + + (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.
Re: Suggestion: DictionaryField
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 with autocompletion; 2) + + (maybe) radio buttons as it should be allowed to choose from existing and to create new dictionary item. 2010/1/17 Łukasz Rekucki> Could you describe this more closely? I don't think I quite follow. > What those auto-generated tables would contain? What would be > acceptable values for this field ? > -- > Łukasz Rekucki > > -- regards, Mihail -- 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.
Suggestion: DictionaryField
Hi, Community Sometimes an application model include a lot of fields which are just dictionary values. Example: class HDD(models.Model): form_factor = models.ForeignKey(HDDFF) capacity = models.ForeignKey(HDDCap) interface = models.ForeignKey(HDDIntf) ... and so on, where HDDFF, HDDCap and HDDIntf are similar classes. Abstract class with only one field "name" may be used, so that this classes could be defined like this: class HDDFF(DictModel): pass but it is not as good as something like this: class HDD(models.Model): form_factor = models.DictionaryField() capacity = models.DictionaryField() interface = models.DictionaryField() Database tables "hdd_form_factor_dict", "hdd_capacity_dict" and so on could be created automatically, just like it is done by ManyToManyField. What do you think about that? -- 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.