Hi fellow devs,
Happy new year everyone. I hope you did not party too much... <:-) I just returned from my snowboard holidays in Ischgl, Austria, with a lot of stuff I thought about... :-D
I've built myself a little test machine that is running Apache 2.0.48, php 5.0.0 (latest CVS) and MySQL 4.1.1 (will update to 5.0.0 soon) on Fedora Core 1 (Linux 2.4.24).
The special thing about it is that I've compiled the old MySQL extension (Let's hope the php people won't hit me) as well as MySQLi against my MySQL 4.1.1 client API.
MySQLi is the new MySQL extension that comes with php 5 and is - according to the php dev team - the recommended way to connect to a MySQL 4.1 server. The old extension works fine when linked against a MySQL 4.1 client API, but wouldn't life be boring if everything was that easy? ;-)
This is why I think that we have to support MySQLi sooner or later - the sooner the better... :-)
The thing is, that the MySQLi architechture differs from the one of the old extension. This is why I want to replace mysql_wrappers by a more abstract interface. I thought about a plugin-like architechture like we already use it for our authentification and export libraries.
Attached to this mail, you find an example library file which contains a connect procedure for the classic MySQL extension. It shall give you a small impression of how I imagined it to be.
Alternatively, we could think about using an external abstraction layer, like PEAR::DB for instance. I haven't worked that much with PEAR::DB, but for my taste it's a little too abstract for a DB administration tool. The other thing is, that PEAR::DB does not have a MySQLi driver so far, we would have to code one anyway...
The other thing is how to realize the multi-charset support in MySQL 4.1. Currently we allow the user to administer the charset settings of his databases, tables and fields, but we still don't give a damn on how the data is inserted into such fields.
As far as I can say, this way should work:
- We only allow UTF-8 language files when connected to a MySQL 4.1 server.
- When connected to a MySQL 4.1 server, we have to bypass all the charset conversion code. For the moment we could do so by manually setting $cfg['AllowAnywhereRecoding'] = FALSE, but later on we have to enable some of it, especially for the import / export features.
- After having connected, we perform the following two queries:
SET CHARACTER SET utf8; SET SESSION character_set_connection = utf8;
- MySQL should now treat everything it receives from PMA as UTF-8 and convert it into the specific field character sets when inserting data as well as reconvert the data to UTF-8 when extracting it.
At the moment I am running some testcases, but they look good so far.
The big problem we will face is, that we have to include select_lang.lib.php AFTER we have connected to the MySQL server. I am currently working on that.
All this stuff will end up in a lot of work, so I will need some help with the concept, the code, ...everything :-) Michal, as the current charset conversion code is your baby, perhaps you have some ideas (and time)?
Furthermore, these changes will take some time to code and debug, so if we wanted a quick 2.5.6, we'd better create a MAINT_2_5 branch for smaller features and fixes and work on 2.6.0 in HEAD.
Comments please. :-)
Regards,
Alexander M. Turek a écrit:
Hi fellow devs,
Happy new year everyone. I hope you did not party too much... <:-) I just returned from my snowboard holidays in Ischgl, Austria, with a lot of stuff I thought about... :-D
I've built myself a little test machine that is running Apache 2.0.48, php 5.0.0 (latest CVS) and MySQL 4.1.1 (will update to 5.0.0 soon) on Fedora Core 1 (Linux 2.4.24).
The special thing about it is that I've compiled the old MySQL extension (Let's hope the php people won't hit me) as well as MySQLi against my MySQL 4.1.1 client API.
MySQLi is the new MySQL extension that comes with php 5 and is - according to the php dev team - the recommended way to connect to a MySQL 4.1 server. The old extension works fine when linked against a MySQL 4.1 client API, but wouldn't life be boring if everything was that easy? ;-)
This is why I think that we have to support MySQLi sooner or later - the sooner the better... :-)
The thing is, that the MySQLi architechture differs from the one of the old extension. This is why I want to replace mysql_wrappers by a more abstract interface. I thought about a plugin-like architechture like we already use it for our authentification and export libraries.
Attached to this mail, you find an example library file which contains a connect procedure for the classic MySQL extension. It shall give you a small impression of how I imagined it to be.
Alternatively, we could think about using an external abstraction layer, like PEAR::DB for instance. I haven't worked that much with PEAR::DB, but for my taste it's a little too abstract for a DB administration tool. The other thing is, that PEAR::DB does not have a MySQLi driver so far, we would have to code one anyway...
The other thing is how to realize the multi-charset support in MySQL 4.1. Currently we allow the user to administer the charset settings of his databases, tables and fields, but we still don't give a damn on how the data is inserted into such fields.
As far as I can say, this way should work:
We only allow UTF-8 language files when connected to a MySQL 4.1 server.
When connected to a MySQL 4.1 server, we have to bypass all the charset
conversion code. For the moment we could do so by manually setting $cfg['AllowAnywhereRecoding'] = FALSE, but later on we have to enable some of it, especially for the import / export features.
- After having connected, we perform the following two queries:
SET CHARACTER SET utf8; SET SESSION character_set_connection = utf8;
- MySQL should now treat everything it receives from PMA as UTF-8 and convert
it into the specific field character sets when inserting data as well as reconvert the data to UTF-8 when extracting it.
At the moment I am running some testcases, but they look good so far.
The big problem we will face is, that we have to include select_lang.lib.php AFTER we have connected to the MySQL server. I am currently working on that.
All this stuff will end up in a lot of work, so I will need some help with the concept, the code, ...everything :-) Michal, as the current charset conversion code is your baby, perhaps you have some ideas (and time)?
Furthermore, these changes will take some time to code and debug, so if we wanted a quick 2.5.6, we'd better create a MAINT_2_5 branch for smaller features and fixes and work on 2.6.0 in HEAD.
Comments please. :-)
Hi Alexander,
When I look at the next jobs for the project, I see 3 main possibilities:
- sessions stuff - evaluate and possibly clear some RFE entries - MySQLi
I offer my help on the MySQLi project. I agree to switch HEAD to 2.6.0 (or maybe name this 3.0) but I suggest that we all concentrate our efforts to MySQLi. This way everyone would be familiar with the new code.
Important bug fixes would go to 2.5.5-pl... and small bug fix would go to HEAD or be delayed.
Marc
Hi Marc & list,
Marc Delisle wrote:
Hi Alexander,
When I look at the next jobs for the project, I see 3 main possibilities:
- sessions stuff
Should also be done, but can wait.
- evaluate and possibly clear some RFE entries
After the session stuff ;-)
- MySQLi
I offer my help on the MySQLi project. I agree to switch HEAD to 2.6.0 (or maybe name this 3.0) but I suggest that we all concentrate our efforts to MySQLi. This way everyone would be familiar with the new code.
Important bug fixes would go to 2.5.5-pl... and small bug fix would go to HEAD or be delayed.
Currently we have some code in HEAD that is ready to release (imho) and does not depend on MySQLi. Regarding the fact that some of it affects the compatibility with recent MySQL releases (4.1.1 and 5.0.0) I really think that we should split the HEAD branch instead of keeping on merging into QA_2_5_5.
We won't have to create QA sub-branches of MAINT_2_5. It's just that I think that the MySQLi work will take some time so we should at least keep the possibility of releasing on or two more 2.5.x releases in the meantime.
Regards,
--
Alexander M. Turek rabus@users.sourceforge.net _ __ __ _ _ _ _ __ | |__ _ __ | / |_ _ / \ __| |_ __ ___ (_)_ __ | '_ | '_ | '_ | |/| | | | | / _ \ / _` | '_ ` _ | | '_ \ | |_) | | | | |_) | | | | |_| |/ ___ \ (_| | | | | | | | | | | | .__/|_| |_| .__/|_| |_|__, /_/ ___,_|_| |_| |_|_|_| |_| |_| |_| |___/ http://www.phpmyadmin.net
Alexander M. Turek a écrit:
Hi Marc & list,
Marc Delisle wrote:
Hi Alexander,
When I look at the next jobs for the project, I see 3 main possibilities:
- sessions stuff
Should also be done, but can wait.
- evaluate and possibly clear some RFE entries
After the session stuff ;-)
- MySQLi
I offer my help on the MySQLi project. I agree to switch HEAD to 2.6.0 (or maybe name this 3.0) but I suggest that we all concentrate our efforts to MySQLi. This way everyone would be familiar with the new code.
Important bug fixes would go to 2.5.5-pl... and small bug fix would go to HEAD or be delayed.
Currently we have some code in HEAD that is ready to release (imho) and does not depend on MySQLi. Regarding the fact that some of it affects the compatibility with recent MySQL releases (4.1.1 and 5.0.0) I really think that we should split the HEAD branch instead of keeping on merging into QA_2_5_5.
We won't have to create QA sub-branches of MAINT_2_5. It's just that I think that the MySQLi work will take some time so we should at least keep the possibility of releasing on or two more 2.5.x releases in the meantime.
Regards,
Hi all,
as suggested by Alexander I have started the MAINT_2_5 branch. In this we will merge stuff for the next 2.5.x releases, but not forgetting to synchronize the changes with the HEAD branch, which will be used for MySQLi stuff.
Marc
-
Alexander M. Turek -
Marc Delisle -
Marc Delisle