On Wednesday 26 June 2013, Patryk Ściborek wrote:
> W dniu środa, 26 czerwca 2013 17:26:12 UTC+2 użytkownik Carl Meyer napisał:
> > Do you have any new information to justify why the existing resolution
> > of #2239 should be reconsidered?
> >
> > I think the existing resolution is correct. This seems like a perfect
> > case for a third-party field class. I don't think the need to represent
> > MAC addresses in the database is common enough in web development to
> > warrant inclusion in Django core.
>
> Hi!
>
> I agree it can be solved by third-party code - this is the way I do it
> right now. Unfortunately there is one thing which can't be done this way -
> database introspection. Maybe I'm wrong and it is possible to extend
> introspection code?
>
Obviously, you would need backend-specific code -- and the place for such code
is the database backend. So, to add new introspection capabilities, esp. if
you are only interested in Postgresql (as I suspect you wouldn't want to
declare any varchar(17) field as a MAC address field), you need to make a
custom
database backend.
While it is not as well supported or documented as custom fields, writing
adaptations to database backends by inheriting from classes in the existing
ones is not too hard. I've been doing it for quite a long time with the Oracle
backend.
HTH,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
