<br><br><div class="gmail_quote">On Thu, May 14, 2009 at 12:54 PM, Jeff Mitchell <span dir="ltr"><<a href="mailto:mitchell@kde.org">mitchell@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Mark Kretschmann wrote:<br>
> Hi Stanislav, big thanks for diagnosing this issue.<br>
<br>
</div>Indeed.<br>
<br>
Question: what distributions have this problem?<br>
<br>
On Gentoo at least, utf8 is the default -- you have to explicitly force<br>
it to use latin1 as the default (compile time option), or explicitly<br>
specify latin1 when creating a table.  I would have thought this would<br>
be the case for most unicode-friendly distributions, i.e. almost any<br>
modern distribution.<br>
<br>
This isn't to say we shouldn't try to fix it on our end; however, I<br>
think this is also something we should be asking packagers.<br>
<br>
For the #1 fix:<br>
<br>
The problem I see here is that for people using problematic mysql<br>
packages, any new table or field that is created will not use the right<br>
encoding.  So this is at best a temporary fix, and one that we have to<br>
then remember to carry forward.  I foresee future bug reports.<br>
<br>
As for the #2 fix:<br>
<br>
When any database update is performed, a full rescan is run, which drops<br>
pretty much all data with the exception of a few key tables.  I don't<br>
believe the values in those tables will generally have problems with<br>
becoming non-unique after encoding changes.  But you mention other issues.<br>
<br>
<br>
I think that there's only one right way to do this:<br>
<br>
1) Clear the tables that would be wiped clean by a full rescan anyways.<br>
2) Create a new DB, and dump the remaining data over.<br>
3) Create the old one again, with the right encoding by default.<br>
4) Dump the data back over.<br>
<br>
<br>
I actually would support doing this before 2.1 release, and having<br>
people using SVN test it out.  I'm pretty comfy (compared to most) with<br>
the DB code and think I could get this done.  Otherwise, I think the<br>
entire fix would have to wait for 2.2, which will be who-knows-how-far-away.</blockquote><div><br>I don't agree with doing this for 2.1. Regardless of how comfortable anyone is with the code, we've already released beta2 and have maybe 1 more RC left. This is not the time for *any* major changes, regardless of how straightforward. And i know you're going to say it's not a major change, but when it has the potential to affect every user's collection, it's pretty important. we do have 2.1.1, it's not like 2.1.0 is our last release until 2.2.<br>
<br>just look at what happened with max's commit to the collection code---he knows it well, it was an easy fix, but it still b0rked collections and took a day of people complaining to track it down properly. this is not something to be experimenting with days before a major release.<br>
<br>leo<br></div></div><br><br clear="all"><br>-- <br>______________________________________________________<br>Leo Franchi                    <br>7016 Wandering Oak          <a href="mailto:lfranchi@kde.org">lfranchi@kde.org</a><br>
Austin                        <a href="mailto:leonardo.franchi@tufts.edu">leonardo.franchi@tufts.edu</a>                                 cell: (650) 704 3680<br>TX, USA                              home: (650) 329 0125<br>
<br>