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

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>>>
>>>> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>>>>
>>>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>>>
>>>>>> Quoting Vilius ?umskas <vilius at lnk.lt>:
>>>>>>
>>>>>>>>> I remember some discussion had been had about tracking down the
>>>>>>>>> problems that Jan and Michael were seeing - where is this? My recent
>>>>>>>>> experience is that SET NAMES is definitely the way to go and that
>>>>>>>>> things aren't doing what you think they are without it, so I'd like
>>>>>>>>> to resolve this and get that functionality back in.
>>>>>>>>
>>>>>>>> Well, if someone comes up with a failing unit test for the Share or Db
>>>>>>>> library, I'll definitely take another look. But at the moment all
>>>>>>>> charset relatet tests pass just fine.
>>>>>>>
>>>>>>> I don't know how to write a unit test but I just tried  
>>>>>>> Horde4-git today and as said before current implementation  
>>>>>>> works only with utf-8 charset. Any other charsets are failing.  
>>>>>>> Just tried with cp1257 and Cyrilic charsets and getting  
>>>>>>> question marks instead of needed characters.
>>>>>>>
>>>>>>> | Administrator | horde      | identities      |  
>>>>>>> a:1:{i:0;a:6:{s:16:"default_identity";i:0;s:9:"from_addr";s:0:"";s:8:"fullname";s:15:"Vilius ?umskas";s:2:"id";s:21:"Standartinis apra?as";s:10:"identities";s:6:"a:0:{}";s:10:"properties";N;}}  
>>>>>>> |
>>>>>>
>>>>>> Can you write up some simple code using Horde_Db that  
>>>>>> demonstrates the problem? I can take care of turning it into a  
>>>>>> unit test.
>>>>>
>>>>> FWIW, Vilius' earlier email in this thread really clarified  
>>>>> things for me, and filled in the holes that I was missing  
>>>>> regarding what was going on between horde <--> mysql, and I  
>>>>> think it makes sense to (re)add it.  The problems that I think I  
>>>>> had with it was due to corrupt/incorrectly encoded data that  
>>>>> existed in the database(s) I was testing. I also posted a link  
>>>>> to an article I found that I think explained why I was having  
>>>>> these difficulties. If needed, I can dig up the link again.
>>>>
>>>> Alright, I just pushed a few commits that re-add the SET NAMES  
>>>> call, including tests for both utf8 and cp1257 character  
>>>> passthrough. Thanks to everyone for the input/feedback.
>>>
>>> This test is not very helpful because if passes just fine with the  
>>> SET NAMES patch reverted again. (besides getCharset() not being  
>>> available obviously).
>>
>> Hmm, it didn't for me. What native charset are you running MySQL as?
>
> The server is running as utf-8, the test database as latin1.

As I understand it databases don't really have charsets in MySQL -  
there are the server settings, and column level settings. Everything  
else is a default. So the fact that your server is already utf-8  
likely explains why things work for you...

-chuck