[sclug] URL encoding/decoding question

[Pieter Claassen]

> Umm, how long ago; before or after reloading the database to change
> encoding?
>
This was before reloading it so you might be right that an alter statement
might not be enough and that data will have to be reloaded.

The issue at the moment is that mysql is broken and I cannot recreate the
round trip until I have fixed it. I upgraded mysql to 4.1 because it was
clear that it had better unicode support that 4.0 (which under
ubuntu/debian does not have utf8 support compiled in).

Tomcat seems to use preparedstatement internally for authentication so
there is no real option other than solving the problem.


> You've misunderstood, it's not a question of not _supporting_ it,
> prepared statement execution is typically _faster_ than than using the
> query cache and, as a result, MySQL doesn't even refer to its query
> cache when you are executing a prepared statement.
>

As I mentioned above, mysql-server  4.1.12-1ubuntu3.1 with
mysql-connector-java-[3.1.12|5.0.0-beta|5.0.0-nightly-20060223] fails to
substitute the variable values in the preparedstatement line.
setString(...) fails. I suspect that it is because it is caching the
prepare statement  and then when executing it (pulls the statement from
the cache) tries to execute the literal SQL query. The MySQL recommended
methods to disable sql caching still results in mysql reporting that the
cach is enabled but just 0 bytes large. Not sure what that means.

9 Prepare     [1] SELECT SQL_NO_CACHE data FROM content WHERE lang=?
9 Execute     [1] SELECT SQL_NO_CACHE data FROM content WHERE lang=?


> I don't understand why you are raising this now though; what has it to
> do with your character encoding problem?


> Where are those Ethereal dumps? These will tell us exactly what's going
> on, rather than messing about with random tinkering. (Empirical method:
> measure first.)

I will produce them (and have been trying to) as soon as I have a db that
can do preparedstatement otherwise they are meaningless.

I just tested and the problem does not exist in MySQL 5.0.18.

Cheers,
Pieter



>
> - Raz
>
>
>
>