On May 20, 9:01 am, Justin Bronn <[EMAIL PROTECTED]> wrote: > I'm with Malcolm on not supporting this feature of > automatically casting to string because the database is doing the > "right thing" here. [1]
It's certainly the right thing to do in general. I'd like to mention one use of the implicit conversion performed by older PostgreSQL versions that I'm making use of, and others might unknowingly also: Using a CharField or SlugField as the object_id field of a generic foreign key. This allows the key to relate to both string-keyed objects and integer-keyed objects. This is fairly gross DB design; in my app it could be worked around by using surrogate ID keys (along with a lot of data munging, but that's automatable). The problem comes with targeting a generic foreign key at models from third party apps, over whose keys users don't have control. There's certainly a fix for the situation, either something simple that I've missed or perhaps adding a shim to explicitly coerce values only for desired cases. -Jim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
