Jay Pipes wrote:
Jim Starkey wrote:
Another issue with LOAD DATA is the location of character set
handling. As I understand it, the drizzle server is all utf-8 with
translations between utf-8 and local character sets handled client
side. The goal, I presume, is to eliminate all character set
conversion code from the server. If this is the case, shipping files
encoded with local character sets to the server for processing is a
serious problem, requiring character set tracking and conversion in
multiple locations.
AFAIU, this is no different from the current MySQL, where one must
convert both on the client (SET NAMES utf8).
Ideally, if a file is encoded in latin-1 or some other non-UTF8
charset, then the client would encode into UTF8 and be done with it.
The idea to simplify to only UTF8 is to simplify *the server*, which
is what Drizzle focuses on. If a client (drizzle or otherwise) wishes
to pre-convert or post-convert to another character set (for instance,
because the underlying programming language does not handle UTF8
properly), then so be it, no?
How does Nimbus handle this? Does the server handle all charset
conversion in the same way (not necessarily the same design) as MySQL?
Nimbus, like Falcon, is 100% unicode. The engine, per se, uses only
UTF-8; the JVM, of course, uses UTF-16. Falcon treats character data
from MySQL as "opaque".
The Nimbus protocols use only utf-8. The client API will probably
convert between utf-8 and the local character if I ever get around to
it. Properly speaking, the Nimbus API is JDBC, which has no truck for
non-unicode character sets. I may become more tolerant in my old age,
but I'm not quite there yet.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
