On Thu, 2007-08-30 at 00:52 +1000, Malcolm Tredinnick wrote: > On Wed, 2007-08-29 at 14:58 +0100, Robin Becker wrote: > > Hi, we're having some troubles with latest django that are caused by the > > switch > > to unicode string output. In particular since we were already carefully > > handling > > the conversion and encoding of the database values we are now getting > > errors > > because the data is in unicode. Is it possible to disable the unicode > > conversion? > > No, it's not possible. The assumptions that strings will already be > Unicode is fairly tightly inter-twined throughout the code. To do > otherwise would, for example, really impact performance because we would > *never* be able to assume that things were in the right encoding and > have to call smart_unicode() everywhere -- the function call overhead > would be noticeable (I say this from having tested it).
Thinking about this for a few minutes more, it might be possible to do a workaround (not something I'd want to put in core, but it might work for your current purposes until binary data transmission is possible). This is only for the database barrier and assuming you are pretty much going from database to models and not doing much else with that data without massaging it further. If you are doing other stuff (particularly sending to templates), things will behave unexpectedly because your encoding won't be UTF-8 (if it was UTF-8, Unicode would just work) and Django has the requirement that bytestrings are UTF-8 encoded. Take one of the existing database backends -- whichever one you're using -- and remove all the setting up of Unicode encoding and decoding. This probably means removing any setting that would return the strings as Unicode (e.g. use_unicode in mysql, the Unicode extension in postgresql_psycopg2, the typecast_string function in postgresql, etc) and anything that converts *to* UTF-8 for transmission to the database. The net effect here would be that models are created with raw bytestrings in whatever format they are returned from the database. Again, this is not a "correct" solution, because it breaks violates some internal invariants. But it might be sufficient for your requirements for the moment if you understand where those invariants are required. Regards, Malcolm -- Quantum mechanics: the dreams stuff is made of. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
