[rt-users] Rt at Glance and upgrade from 3.2.1 to 3.8.0

[Curtis Bruneau]

Curtis Bruneau wrote:
> d tbsky wrote:
>   
>> 2008/8/8 Jean-Michel Barbet <Jean-Michel.Barbet at subatech.in2p3.fr>:
>>   
>>     
>>> d tbsky wrote:
>>>     
>>>       
>>>> hi:
>>>> it is a little fix.almost the same as 3.8.0. and utf8 fix is what
>>>> we need. so i don't need to tune mysql utf8 parameter.
>>>>       
>>>>         
>>> After looking at the way the mysql update procedure works, I believe
>>> it only changes the column charset and collatiin definition, *not the
>>> data*, so if some data where stored in latin1 in my previous Mysql
>>> 4.0 database, the column type will change to binary, then to utf8
>>> and data will not be displayed correctly.
>>>     
>>>       
>>   yes the data are converted to utf8, so rt must treat them as utf8.
>> but mysql default use latin1 for connection, so the data are corrupt
>> when present  in the browser. either patch rt (rt 3.8.1rc2) or force mysql
>> client parameters to use utf8 connection and we can have utf8 from
>> mysql to browser.
>>   
>>     
> I have an issue during conversion where it sees all the accents as the 
> same (in the database with the unique key on name in Users). It should 
> see them as distinct after conversion. Do the temp tables use it's own 
> charset? I remember mssql use to have a similar issue where the system 
> default could be different from the database and joins and such go all 
> wrong.. Are the temp tables possibly not doing UTF*? I'm not 100%, to 
> get around it before i just did a straight alter with no binary, but i 
> think it was storing latin1 inside utf8 fields.. so now I have the 
> original issue.
>
> ERROR 1062 (23000): Duplicate entry 'securite at test.addy' for key 2
>
> If I.. SELECT name FROM Users WHERE name LIKE 'securite at test.addy';
> securité@test.addy
> securite at test.addy
>
> I tried converting the table by removing the index before hand and it 
> errors the same when i go to put it back.
>
> Does anyone have any insight as to why mysql sees this as the same? the 
> client charset doesn't affect it just the display.
>   
>>> Can other people comment on this ?
>>>
>>>     
>>>       
>>>> by the way, can you use the new "WYSIWYG" editor? i still don't know
>>>> where i can see the result.
>>>>       
>>>>         
>>> If I try to reply to a ticket in RT web interface, there is a tiny
>>> black triangle on top of the message box and it expands in a set of
>>> tools to get rich text, then I click save and I can send the message.
>>>
>>>     
>>>       
>>  that's what i want to ask. after using the editor and save,where can
>> you see the rich text affect? i only see plain text after save. and i
>> get plain text email.
>>  thanks for your help!!
>> _______________________________________________
>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>
>> Community help: http://wiki.bestpractical.com
>> Commercial support: sales at bestpractical.com
>>
>>
>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
>> Buy a copy at http://rtbook.bestpractical.com
>>
>>
>>   
>>     
I looked into this a bit more, It has to do with the default collation 
"utf8_general_ci" which doesn't see accents as distinct ( i think ).
http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html There's 
obviously issues to each one as the rules change.. I also read stuff 
about the server collation affecting sorting also.. I'm going to try 
utf8_unicode_ci but it may have the same issue, I saw someone else use 
utf8_bin to solve the issue. I'll look into it more and post my results.

Curtis