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

[Vilius Šumskas]

> >> 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

True if you don't manage Horde's databases with external tools or if you don't integrate it with other applications.

As far as I remember there were dozen of questions in the mailling list "why phpmyadmin displays my Horde database with wrong characters".

> 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.

I would gladly spare some of my free time for this. I've dealt with web application/MySQL charset problems numerious times before. From my perspective it works very well and consistent. Unless you are in some rare case where it doesn't and which I don't know about. What exactly were the problems?

> 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.

By 'old' and 'new' you mean, you've changed db charset in Horde config?
 
> 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.

1. It takes more space to store the same text. This is simple example:

mysql> create table test (tekstas VARCHAR(255)) ENGINE=MyISAM;
Query OK, 0 rows affected (0.06 sec)

mysql> insert into test set tekstas='Premjera bus gruodžio 3 dieną, 19 val. "Forum Cinemas Vingis"';
Query OK, 1 row affected (0.00 sec)

mysql> set names utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test set tekstas='Premjera bus gruodžio 3 dieną, 19 val. "Forum Cinemas Vingis"';
Query OK, 1 row affected (0.00 sec)

mysql> select length(tekstas) from test;
+-----------------+
| length(tekstas) |
+-----------------+
|              68 |
|              63 |
+-----------------+
2 rows in set (0.00 sec)

You can imagine how numbers differ if you have russian or other non latin text.

2. It confuses and irritates administrators as they spent hours debuging why the same text is shown ok in one application but badly in the second. And I must remind you that administrators are these people that bring Horde to users... At least most of the time.

3. Sorting of data is inefficient and in bad order. For example Turba contacts with special characters in their surnames.

-- 
  Vilius