Re: Suggestion: DictionaryField

2010-01-22 Thread veena
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

2010-01-18 Thread veena
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 Lukin  wrote:
> 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

2010-01-18 Thread sago
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 Baburov  wrote:
> 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

2010-01-17 Thread Yuri Baburov
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

2010-01-17 Thread 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.

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

2010-01-16 Thread Михаил Лукин
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

2010-01-16 Thread Mihail Lukin
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.