5 Jan
2004
5 Jan
'04
7:24 a.m.
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
<rabus(a)users.sourceforge.net>
_ __ __ _ _ _
_ __ | |__ _ __ | \/ |_ _ / \ __| |_ __ ___ (_)_ __
| '_ \| '_ \| '_ \| |\/| | | | | / _ \ / _` | '_ ` _ \| | '_ \
| |_) | | | | |_) | | | | |_| |/ ___ \ (_| | | | | | | | | | |
| .__/|_| |_| .__/|_| |_|\__, /_/ \_\__,_|_| |_| |_|_|_| |_|
|_| |_| |___/
<http://www.phpmyadmin.net>
begin 666 mysql.dbi.lib.php
M/#]P:'
-"B\J("1)9"0@*B\-"B\O('9I;3H@97AP86YD=&%B('-W/30@=',]
M-"!S=',]-#H-"@T*+RHJ#0H@*B!);G1E<F9A8V4@=&\@=&AE(&-L87-S:6,@
M37E344P@97AT96YS:6]N#0H@*B\-"@T*<F5Q=6ER95]O;F-E*"<N+VQI8G)A
M<FEE<R]C:&%R<V5T7V-O;G9E<G-I;VXN;&EB+G!H<"<I.PT*#0HO+R!->5-1
M3"!C;&EE;G0@05!)#0II9B H(61E9FEN960H)U!-05]-65-13%]#3$E%3E1?
M05!))RDI('L-"B @(" D8VQI96YT7V%P:2
](&5X<&QO9&4H)RXG+"!M>7-Q
M;%]G971?8VQI96YT7VEN9F\H*2D[#0H@(" @9&5F:6YE*"=034%?35E344Q?
M0TQ)14Y47T%022<L("AI;G0I<W!R:6YT9B@G)60E,#)D)3 R9"<L("1C;&EE
M;G1?87!I6S!=+" D8VQI96YT7V%P:5LQ72P@:6YT=F%L*"1C;&EE;G1?87!I
M6S)=*2DI.PT*("
@('5N<V5T*"1C;&EE;G1?87!I*3L-"GT-"@T*9G5N8W1I
M;VX@4$U!7V-O;FYE8W0H)'5S97(L("1P87-S=V]R9"D@>PT*(" @(&=L;V)A
M;" D8V9G+" D<&AP7V5R<F]R;7-G.PT*#0H@("
@)'-E<G9E<E]P;W)T(" @
M/2 H96UP='DH)&-F9ULG4V5R=F5R)UU;)W!O<G0G72DI#0H@(" @(" @(" @
M(" @(" @(" @/R G)PT*(" @(" @(" @(" @(" @("
@(#H@)SHG("X@)&-F
M9ULG4V5R=F5R)UU;)W!O<G0G73L-"B @("!I9B H<W1R=&]L;W=E<B@D8V9G
M6R=397)V97(G75LG8V]N;F5C=%]T>7!E)UTI(#T]("=T8W G*2![#0H@(" @
M(" @("1C9F=;)U-E<G9E<B==6R=S;V-K970G72 ]("<G.PT*("
@('T-"@T*
M("
@("1S97)V97)?<V]C:V5T(#T@*&5M<'1Y*"1C9F=;)U-E<G9E<B==6R=S
M;V-K970G72DI#0H@(" @(" @(" @(" @(" @(" @/R G)PT*("
@(" @(" @
M(" @(" @("
@(#H@)SHG("X@)&-F9ULG4V5R=F5R)UU;)W-O8VME="==.PT*
M#0H@(" @:68@*%!-05]-65-13%]#3$E%3E1?05!)(#X](#,R,S0Y*2![#0H@
M(" @(" @("1C;&EE;G1?9FQA9W,@/2 D8V9G6R=397)V97(G75LG8V]M<')E
M<W,G72 F)B!D969I;F5D*"=-65-13%]#3$E%3E1?0T]-4%)%4U,G*2 _($U9
M4U%,7T-,245.5%]#3TU04D534R Z(# [#0H@(" @?0T*#0H@(" @:68@*&5M
M<'1Y*"1C;&EE;G1?8VQA9W,I*2![#0H@(" @("
@("1C;VYN96-T7V9U;F,@
M/2 G;7ES<6Q?)R N("@D8V9G6R=097)S:7-T96YT0V]N;F5C=&EO;G,G72 _
M("=P)R Z("<G*2 N("=C;VYN96-T)SL-"B @(" @("
@)&1B:" ]($ D8V]N
M;F5C=%]F=6YC*"1C9F=;)U-E<G9E<B==6R=H;W-T)UT@+B D<V5R=F5R7W!O
M<G0@+B D<V5R=F5R7W-O8VME="P@)'5S97(L("1P87-S=V]R9"D[#0H@("
@
M?2!E;'-E('L-"B @(" @("
@:68@*"1C9F=;)U!E<G-I<W1E;G1#;VYN96-T
M:6]N<R==*2![#0H@(" @(" @(" @("
D9&)H(#T@0&UY<W%L7W!C;VYN96-T
M*"1C9F=;)U-E<G9E<B==6R=H;W-T)UT@+B D<V5R=F5R7W!O<G0@+B D<V5R
M=F5R7W-O8VME="P@)'5S97(L("1P87-S=V]R9"P@)&-L:65N=%]F;&%G<RD[
M#0H@(" @(" @('T@96QS92![#0H@(" @(" @(" @("
D9&)H(#T@0&UY<W%L
M7V-O;FYE8W0H)&-F9ULG4V5R=F5R)UU;)VAO<W0G72 N("1S97)V97)?<&]R
M=" N("1S97)V97)?<V]C:V5T+"
D=7-E<BP@)'!A<W-W;W)D+"!&04Q312P@
M)&-L:65N=%]F;&%G<RD[#0H@(" @(" @('T-"B
@("!]#0H-"B @("!I9B H
M96UP='DH)&1B:"DI('L-"B @(" @("
@4$U!7V%U=&A?9F%I;',H*3L-"B @
M("!]("\O(&5N9"!I9@T*#0H@("
@:68@*"%D969I;F5D*"=034%?35E344Q?
M24Y47U9%4E-)3TXG*2D@>PT*(" @(" @("!I9B
H(65M<'1Y*"1S97)V97(I
M*2![#0H@(" @(" @(" @("
D<F5S=6QT(#T@;7ES<6Q?<75E<GDH)U-%3$5#
M5"!615)324].*"D@05,@=F5R<VEO;B<L("1D8F@I.PT*(" @("
@(" @(" @
M:68@*"1R97-U;'0@(3T@1D%,4T4@)B8@0&UY<W%L7VYU;5]R;W=S*"1R97-U
M;'0I(#X@,"D@>PT*(" @(" @(" @(" @("
@("1R;W<@(" ](&UY<W%L7V9E
M=&-H7V%S<V]C*"1R97-U;'0I.PT*(" @(" @(" @(" @("
@("1M871C:" ]
M(&5X<&QO9&4H)RXG+" D<F]W6R=V97)S:6]N)UTI.PT*(" @("
@(" @(" @
M(" @(&UY<W%L7V9R965?<F5S=6QT*"1R97-U;'0I.PT*(" @("
@(" @(" @
M?0T*(" @("
@("!]("\O(&5N9"!S97)V97(@:60@:7,@9&5F:6YE9"!C87-E
M#0H-"B @(" @("
@:68@*"%I<W-E="@D;6%T8V@I('Q\("%I<W-E="@D;6%T
M8VA;,%TI*2![#0H@(" @(" @(" @(" D;6%T8VA;,%T@/2 S.PT*(" @("
@
M("!]#0H@(" @("
@(&EF("@A:7-S970H)&UA=&-H6S%=*2D@>PT*(" @(" @
M(" @(" @)&UA=&-H6S%=(#T@,C,[#0H@(" @(" @('T-"B
@(" @(" @:68@
M*"%I<W-E="@D;6%T8VA;,ETI*2![#0H@(" @(" @(" @("
D;6%T8VA;,ET@
M/2 S,CL-"B @(" @(" @?0T*#0H@(" @("
@(&EF*"%I<W-E="@D<F]W*2D@
M>PT*(" @(" @(" @("
@)')O=ULG=F5R<VEO;B==(#T@)S,N,C,N,S(G.PT*
M(" @(" @("!]#0H-"B @(" @("
@9&5F:6YE*"=034%?35E344Q?24Y47U9%
M4E-)3TXG+" H:6YT*7-P<FEN=&8H)R5D)3 R9"4P,F0G+" D;6%T8VA;,%TL
M("1M871C:%LQ72P@:6YT=F%L*"1M871C:%LR72DI*3L-"B @(" @("
@9&5F
M:6YE*"=034%?35E344Q?4U127U9%4E-)3TXG+" D<F]W6R=V97)S:6]N)UTI
E.PT*(" @('T-"@T*(" @(')E='5R;B D9&)H.PT*?0T*#0H_/@``
`
end
6 Jan
6 Jan
1:32 a.m.
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
9 Jan
9 Jan
9:48 a.m.
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(a)users.sourceforge.net>
_ __ __ _ _ _
_ __ | |__ _ __ | \/ |_ _ / \ __| |_ __ ___ (_)_ __
| '_ \| '_ \| '_ \| |\/| | | | | / _ \ / _` | '_ ` _ \| | '_ \
| |_) | | | | |_) | | | | |_| |/ ___ \ (_| | | | | | | | | | |
| .__/|_| |_| .__/|_| |_|\__, /_/ \_\__,_|_| |_| |_|_|_| |_|
|_| |_| |___/
<http://www.phpmyadmin.net>
12 Jan
12 Jan
5:46 a.m.
Alexander M. Turek a écrit:
Hi Marc & list,
Marc Delisle wrote:
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
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,
7501
days inactive
7508
days old
3 comments
3 participants
participants (3)
-
Alexander M. Turek -
Marc Delisle -
Marc Delisle