This portability by the lowest common denominator is a screwed up way of thinking (IMHO).
I mean.. how many people write apps and suddenly switch backends half way through development? Having them in the core with a big warning saying that they are mysql only would be ok I think. (similar to the full text search). as I don't see the difference to having a line importing them from contrib vs importing them from django.db.models.fields.mysqlspecific.py for example BTW.. I'm looking at the code, and I don't see how this code would actually create these fields, or are you thinking it would be for legacy databases? regards Ian On 17/07/2006, at 6:36 PM, Geert Vanderkelen wrote: > > Hi! > > I was a bit playing around and missed MySQL ENUM and SET column types. > Instead of adding them to the MySQL backend, I just created a new > app in the > contrib/ directory called 'mysqlext'. > > http://some-abstract-type.com/code/? > cmd=manifest;manifest=76d4a786cf3bd215546af6f1bcf2d12309515d43;path=/d > jango/contrib/ > > This was a workable hack ;) > > It wasn't really difficult to extend the field types, but do you > guys see it > going into the main stream contrib/ of Django one day? > > I'll see if I can add some more stuff there later on. I would like > to have > ENGINE choice per Model. > > This mysqlext would contain stuff which really shouldn't go in the > MySQL > backend of Django itself as it ain't fully compatible with others > (I think > that's the idea of these I guess..). > > Cheers, > > Geert > > -- > Geert Vanderkelen > http://some-abstract-type.com > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
