Proliferation of DB FieldTypes
d...@simon.net.nz
I've been digging through Trac and found that there's a number of
tickets related to adding new database Field types:
http://code.djangoproject.com/ticket/1466 USZipCodeField
http://code.djangoproject.com/ticket/1636 CIDR Datatype
http://code.djangoproject.com/ticket/1642 DirPathField
http://code.djangoproject.com/ticket/2239 EthernetAddress
http://code.djangoproject.com/ticket/2307 Enhanced PhoneNumberField
http://code.djangoproject.com/ticket/2455 USStateField
http://code.djangoproject.com/ticket/3194 Telephone and City Fields
Many of these have working patches and are ready to go, but I'm
wondering if we want to proliferate the number of field types? I think
that adding too many of these is just adding clutter ( e.g.
EthernetAdress vs. IPAddress vs. CIDR etc ) and especially since a
CharField would handle most of these. An alternative may to place these
extras in django.contrib somewhere and allow the user to import them
when they need more than the core field types.
Opinions?
--Simon
Jeremy Bowers
>
> Evening all,
>
> I've been digging through Trac and found that there's a number of
> tickets related to adding new database Field types:
alleviate the need to centralize some of the smaller field types.
As for clutter, I'd worry more about documentation clutter than code
clutter; Django may already be at the point where the main Model page
should only document the "primary" field types and have a full page
dedicated to a complete listing of provided field types.
If there is interest in either of these, I'm willing to take it on.
Gary Wilson
> Many of these have working patches and are ready to go, but I'm
> wondering if we want to proliferate the number of field types? I think
> that adding too many of these is just adding clutter ( e.g.
> EthernetAdress vs. IPAddress vs. CIDR etc ) and especially since a
> CharField would handle most of these. An alternative may to place these
> extras in django.contrib somewhere and allow the user to import them
> when they need more than the core field types.
>
> Opinions?
I think that the addition of fields that are generally useful (and I
would say that most of the above are) would be a good thing. It would
keep people from duplicating work (and bugs). Plus, maybe not everyone
who needs an international phone number field would be able to
implement it themselves.
As far as whether to put them in contrib or not, I say heck, why not
just stick them with the rest (even if that means in the __init__.py
files where I don't think any of that should be, but that's another
discussion).
telenieko
Some of those fields could, maybe, be solved on a way like the one I just submitted to #1636. Basically IPAddressField could have an option about whether it should or shouldn't accept cidr notation IP's as the field is **almost** the same it could be an elegant way to have both in one ;)
On fields like USZipCode or USState and those which are **really** region speciffic could be put on contrib (why would somebody outside US want those fields? ie) we could end up with SpainRegion, CaribeanIsland... you get the idea.
Phone Numbers could be solved with a "RegexField" that validates values against a given regex expression, then just fill a Wiki page with lots of regex examples "US Phone number", "Spain phone number", "US Toll free number" and so on. Then the "US related fields contrib" could add all the phone type fields from the base RegexField (by simply setting the regex there transparently to the user/developer).
Just my 0.02,
Marc.
PS: Ethernet can also be a Regex unless you want fuzzy things like "field.manufacturer, field.is_locally_administrated, field.manufacturer_bits, field.device_bits" etc.
Jeremy Dunck
...
> On fields like USZipCode or USState and those which are **really** region
> speciffic could be put on contrib (why would somebody outside US want those
> fields? ie) we could end up with SpainRegion, CaribeanIsland... you get the
> idea.
It seems to me that all these things are CharField + some validators.
How about a decorator over constructors?
USZipCode = FieldWithValidation(CharField, [isUSZip])
chris....@gmail.com
http://webda.python-hosting.com/
Including, countries, areas (states, etc), languages, phone numbers.
It already had Django modules so it could be a good contrib to add.
I do agree that most of these are char fields and the
FieldWithValidation syntax might make it pretty simple.
Kyujin Shim
>
> USZipCode = FieldWithValidation(CharField, [isUSZip])
How about this syntax? something like oldform style?
USZipCode = CharField( validators=[isUSZip] )