[dev] [commits] Horde branch master updated. fa8d644f8ca59a43056e5eae668ff1699d36be24

[Jan Schneider]

Zitat von Vilius ?umskas <vilius at lnk.lt>:

>> commit fa8d644f8ca59a43056e5eae668ff1699d36be24
>> Author: Jan Schneider <jan at horde.org>
>> Date:   Tue Nov 30 15:41:59 2010 +0100
>>
>>     Remove charset methods.
>>
>>     They are only implemented in the MySQL drivers anyway and using SET
>>     NAMES causes more problems than it solves. Actually it breaks the
>>     current share driver.
>
> Does this mean that it will not be implemented and we are stuck with  
> ISO-8859-1 connection charsets forever? Horde is the only  
> professional application which doesn't use charsets correctly on DB  
> level.

DB charset handling has always worked fine in Horde. I removed this  
stuff from Horde_Db because we spent almost an hour with two  
developers to find out why we had some broken charset conversions with  
the current Horde_Db code. We tried to align the MySQL documentation  
with the behavior we've been seeing in different environments, to no  
avail. It doesn't work as documented, and it doesn't work well either.  
In the end, after we removed the SET NAMES call, everything started to  
work properly again, with old data, with new data, with UTF-8 data,  
with Latin1 data.

Unless someone comes up with a convincing explanation, why SET NAMES  
is really necessary, and shows me consistent, working, documented  
behavior with different charsets and existing as well as new data,  
plus an implementation that works with other databases too and with  
the way we do charset conversions in Horde, this won't be added back.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/