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
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
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
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
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
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 =
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