Hi, Ivan Sagalaev schrieb: > Michael Radziej wrote: >> I'm not sure about what the last sentence means--are you suggesting to >> put #3370 (the mysql part) into "Needs design decision"? > > ## 3370 > > I'm -1 on setting MySQL connection to 'utf8' in #3370. It *will* make > sense when we will have newforms ready and models containing unicode. > But now most of Django is a byte string country. A bright example are > generic views that take data from web and store it to models without any > conversions. This patch will feed 'windows-1251' or 'iso-8859-1' to > MySQL saying that "it's utf-8" and MySQL will try to convert it and most > certainly will store just strings of '????'. The patch is working for > the author only because it feeds newforms' unicode objects right into > models which is wrong (we hadn't convert models to unicode yet).
Ah, I see. Somehow it wasn't clear to me that POSTs and GETs are just passed along, but now that you mention it, it looks so obvious. Thanks, that was the missing piece that kept me from proper understanding. > But the __repr__ part is plain incorrect: Now, let's keep __repr__() apart, it's a different issue. We can come back to it later. > ## 952 > > This patch tries to set connection encoding to the one used for web: > DEFAULT_CHARSET. But when we convert Django to unicode (we'll have to do > it anyway because of newforms) this won't be necessary because models > will be unicodified too. Then it'll make sense to set 'utf8' in all > backends as a connection encoding. Hey, I now finally understand why you need #952 as soon as you switch to a different charset. I understand your point, but I'd rather offer a solution than postponing this for such a long time. > ## Suggestion > > Now I think we should close all these bugs. Don't laugh (or cry)! #952 > is neither long-term nor helps ak's case, #3370 is broken (sorry, ak, > but it is) and #1356 is a dupe of #3370. I agree to close #1356 and #3370, but #952 seems to be valuable independent of ak's case. I'd rather put #952 into "Needs design decision", because that's really the realm of the core to decide, but it looks a bit that Adrian has already accepted it (as he reopened it). SmileyChris, you did the initial triage on #952, do you read me? What's your opinion here? As I said, this is __repr__() kept aside. Let's tackle it after the connection encoding. Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
