[Phpmyadmin-devel] Nuke mysql_wrappers?

[Marc Delisle]

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