Re: broken DBD-mysql-2.9002 (fixed)

am 26.09.2003 17:40:18 von Wolfgang Friebel

On Fri, 26 Sep 2003, Jochen Wiedmann wrote:

>
> Hi, Wolfgang,
>
> as Rudy is *the* maintainer nowadays, I am simply forwarding your mail to
> the relevant mailing list.

Thanks,

meanwhile by trial and error I found the bug that causes the weird
behaviour. This time it was just too much code.

If I do remove the subroutine get_info (lib/DBD/mysql.pm, line 414):

####################
# get_info()
# Generated by DBI::DBD::Metadata

sub get_info {
my($dbh, $info_type) = @_;
require DBD::mysql::GetInfo;
my $v = $DBD::mysql::GetInfo::info{int($info_type)};
$v = $v->($dbh) if ref $v eq 'CODE';
return $v;
}

the sample script provided with the previous mail gives the expected
output also with DBD-mysql-2.9002.

Best regards
--
Wolfgang Friebel
Deutsches Elektronen-Synchrotron DESY | Phone: +49 33762 77372 |
Platanenallee 6 | Fax: +49 33762 77216 |
D-15738 Zeuthen Germany | E-Mail: Wolfgang.Friebel@desy.de |

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: broken DBD-mysql-2.9002 (fixed)

am 26.09.2003 17:59:55 von Rudy Lippan

On Fri, 26 Sep 2003, Wolfgang Friebel wrote:

> On Fri, 26 Sep 2003, Jochen Wiedmann wrote:
>
> >
> > Hi, Wolfgang,
> >
> > as Rudy is *the* maintainer nowadays, I am simply forwarding your mail to
> > the relevant mailing list.
>
>
> Thanks,
>
> meanwhile by trial and error I found the bug that causes the weird
> behaviour. This time it was just too much code.
>
> If I do remove the subroutine get_info (lib/DBD/mysql.pm, line 414):
>

That is right weird. Than you for the update -- I was just starting to
respond to the first message. It seems that the attachment got lost in
the forward, do you think that you could send it again.

> ####################
> # get_info()
> # Generated by DBI::DBD::Metadata
>
> sub get_info {
> my($dbh, $info_type) = @_;
> require DBD::mysql::GetInfo;
> my $v = $DBD::mysql::GetInfo::info{int($info_type)};
> $v = $v->($dbh) if ref $v eq 'CODE';
> return $v;
> }
>

I don't see what could be causing the problem, offhand. BTA, the existance
of get_info() changes the behaviour of DBI, but even so, what does any of
that have to do with accesing a variable in another package? Maybe I am
missing something here as I have not seen code that causes the problem.

Rudy

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: broken DBD-mysql-2.9002 (fixed)

am 26.09.2003 17:59:55 von Rudy Lippan

Re: broken DBD-mysql-2.9002 (fixed)

am 26.09.2003 18:58:51 von Wolfgang Friebel

--579699202-1654816860-1064595415=:627
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Fri, 26 Sep 2003, Rudy Lippan wrote:

> That is right weird. Than you for the update -- I was just starting to
> respond to the first message. It seems that the attachment got lost in
> the forward, do you think that you could send it again.
>
>
> > ####################
> > # get_info()
> > # Generated by DBI::DBD::Metadata
> >
> > sub get_info {
> > my($dbh, $info_type) = @_;
> > require DBD::mysql::GetInfo;
> > my $v = $DBD::mysql::GetInfo::info{int($info_type)};
> > $v = $v->($dbh) if ref $v eq 'CODE';
> > return $v;
> > }
> >
>
> I don't see what could be causing the problem, offhand. BTA, the existance
> of get_info() changes the behaviour of DBI, but even so, what does any of
> that have to do with accesing a variable in another package? Maybe I am
> missing something here as I have not seen code that causes the problem.
>
Indeed, we are the module still in many other scripts which all do work
flawlessly (afaik).

For completeness: The test script is

#!/opt/products/perl/5.8.0/bin/perl
use Db;
Db::Init_DB();
use Dumpvalue;
$d=new Dumpvalue;
$d->dumpValue(\%Db::);

and the Module Db.pm is attached to this mail

The output with get_info in place is just the ordinary variables:
DBI Version: 1.37
'BEGIN' => *Db::BEGIN
'Connect_DB' => *Db::Connect_DB
'DESTROY' => *Db::DESTROY
'Disconnect_DB' => *Db::Disconnect_DB
'Init_DB' => *Db::Init_DB
'SQL_Query' => *Db::SQL_Query
'col_names_hash' => *Db::col_names_hash
'dbh' => *Db::dbh
'import' => *Db::import
'new' => *Db::new
'pw' => *Db::pw
'tables' => *Db::tables
'user' => *Db::user

while without get_info all the variables that get created from the
contents of the database are printed as well:
DBI Version: 1.37
'BEGIN' => *Db::BEGIN
'Connect_DB' => *Db::Connect_DB
'DESTROY' => *Db::DESTROY
'Disconnect_DB' => *Db::Disconnect_DB
'Init_DB' => *Db::Init_DB
'SQL_Query' => *Db::SQL_Query
'account_filesystem_account_id_hash' =>
*Db::account_filesystem_account_id_hash
'account_filesystem_filesystem_id_hash' =>
*Db::account_filesystem_filesystem_id_hash
'account_filesystem_hash' => *Db::account_filesystem_hash
'account_hash' => *Db::account_hash
'account_mailinglist_hash' => *Db::account_mailinglist_hash
......

Wolfgang
--579699202-1654816860-1064595415=:627
Content-Type: APPLICATION/X-PERL; NAME="Db.pm"
Content-Transfer-Encoding: BASE64
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="Db.pm"

cGFja2FnZSBEYjsKCnVzZSBEQkk7CgpzdWIgSW5pdF9EQgp7CgoJcHJpbnQg
IkRCSSBWZXJzaW9uOiAkREJJOjpWRVJTSU9OXG4iOyAKCW15ICRkYiA9IERi
LT5uZXcoKSBvciByZXR1cm47CgoJCQkjIyMjIGNyZWF0ZSBhcnJheSBvZiB0
YWJsZSBuYW1lcyAjIyMjCglAdGFibGVzID0gc29ydCAkZGItPnsnZGJoJ30t
PnRhYmxlcygpOwoKCQkJIyMjIyBmZXRjaGluZyBkYXRhIGZyb20gdGFibGVz
ICMjIyMKCVRBQkxFUzogZm9yZWFjaCBteSAkdGFibGUgKCBAdGFibGVzICkK
CXsKCQluZXh0IGlmICR0YWJsZSA9fiAvXl9fLzsgIyBpbnRlcm5hbCB0YWJs
ZXMKCQkJCSMjIyMgREJJIHN0YXRlbWVudHMgZm9yIGRhdGFiYXNlIGFjY2Vz
cyAjIyMjCgkJbXkgJHN0aCA9ICRkYi0+U1FMX1F1ZXJ5KCJTRUxFQ1QgKiBG
Uk9NICR0YWJsZSIpOwoKCQkJCSMjIyMgZ2V0IGN1cnJlbnQgdGFibGVzIGNv
bHVtbiBoZWFkZXJzICMjIyMKCQlteSAkY29sdW1ucyA9ICRzdGgtPnsnTkFN
RSd9OwoKCQkjIHNhdmUgdGhlIGRhdGEgdHlwZXMgb2YgZWFjaCBjb2x1bW4K
CQlteSAkcHJlYyA9ICRzdGgtPnsnUFJFQ0lTSU9OJ307CgoJCQkJIyMjIyBm
ZXRjaCBjdXJyZW50IHRhYmxlcyBkYXRhICMjIyMKCQl3aGlsZSAoIG15ICRy
b3cgPSAkc3RoLT5mZXRjaHJvd19hcnJheXJlZigpICkKCQl7CgkJCW15ICRp
ID0gLTE7CgkJCW15ICRpZCA9ICRyb3ctPlswXTsKCQkJZm9yZWFjaCAoIEB7
JHJvd30gKQoJCQl7CgkJCQlteSAkY29sID0gJGNvbHVtbnMtPlsrKyRpXTsK
CQkJCW5leHQgaWYgJGNvbCBlcSAnVVNFUicgb3IgJGNvbCBlcSAnVElNRSc7
CgkJCQkjYnVpbGQgdXAgaGFzaCBmb3IgYWNjZXNzIG92ZXIgdGFibGUtaWQK
CQkJCSR7JHRhYmxlLidfaGFzaCd9eyRpZH17JGNvbHVtbnMtPlskaV19ID0g
JF87CgkJCX0KCQl9CgoJCSRzdGggPSAkZGItPlNRTF9RdWVyeSgiREVTQyAk
dGFibGUiKTsKCgkJbXkgJGkgPSAtMTsKCQkjY3JlYXRlcyBzb21lIGhhc2hl
cyBmb3IgaW1wcm92ZWQgYWNjZXNzIG9uIGRhdGEgc2V0IGVudHJpZXMKCQlD
T0wxOiBmb3JlYWNoIG15ICRjb2wxIChAJGNvbHVtbnMpCgkJewoJCQlteSAk
aW5mbyA9ICRzdGgtPmZldGNocm93X2hhc2hyZWYoKTsKCQkJJGkrKzsKCQkJ
bmV4dCBpZiAkY29sMSBlcSAnVVNFUicgb3IgJGNvbDEgZXEgJ1RJTUUnOyAK
CQkJIyBzYXZlIHRoZSBuYW1lcyBvZiBjb2x1bW5zIGFuZCB0aGVpciBwcmVj
aXNpb24KCQkJJGNvbF9uYW1lc19oYXNoeyR0YWJsZX17JGNvbDF9eydwcmVj
J30gPSAkcHJlYy0+WyRpXTsKCQkJJGNvbF9uYW1lc19oYXNoeyR0YWJsZX17
JGNvbDF9eydkZWZhdWx0J30gPSAkaW5mby0+eydEZWZhdWx0J307CgkJCW15
ICR0eXBlID0gJGluZm8tPnsnVHlwZSd9OwoJCQlpZiAoICR0eXBlID1+IHMv
XnNldFwoKC4rKVwpJC8kMS8gKQoJCQl7CgkJCQkkdHlwZSA9fiBzL1wnLy9n
OwoJCQkJQHskY29sX25hbWVzX2hhc2h7JHRhYmxlfXskY29sMX17J3ZhbHVl
cyd9fSA9IHNwbGl0IC8sLywgJHR5cGU7CgkJCX0KCgkJCSMgb25seSBjb2x1
bW5zIHRoYXQgZW5kIHdpdGggX2lkIGFzIGhhc2gga2V5cwoJCQluZXh0IENP
TDEgaWYgJGNvbDEgIX4gL19pZCQvOwoKCQkJIyBuYW1lIG9mIGhhc2ggaW4g
d2hpY2ggc3RydWN0dXJlIGlzIHN0b3JlZAoJCQlteSAkaG4gPSAkdGFibGUu
J18nLiRjb2wxLidfaGFzaCc7CgkJCSMgbmFtZSBvZiBoYXNoIGZyb20gd2hp
Y2ggZGF0YSBpcyB0YWtlbgoJCQlteSAkaG4yID0gJHRhYmxlLidfaGFzaCc7
CgoJCQlFTlRSSUVTOiBmb3JlYWNoIG15ICRpZCAoa2V5cyAleyRobjJ9KQoJ
CQl7CgkJCQlteSAkaGlkID0gJHskaG4yfXskaWR9eyRjb2wxfSBvciBuZXh0
OyAjdGhlIGxpbmsgaWQKCQkJCSR7JGhufXskaGlkfXskaWR9ID0gJHskaG4y
fXskaWR9OyAjc2V0IHVwIGxpbmsgaGFzaAoJCQkJIyBlLmcuIGludGVyZmFj
ZV9ob3N0X2lkX2hhc2h7MTAwfXsxfSA9IGludGVyZmFjZV9oYXNoezF9OwoJ
CQkJIyAxMDAgaXMgaG9zdF9pZCwgMSBpcyBpbnRlcmZhY2UgaWQKCQkJfQoJ
CX0KCX0KfQoKc3ViIG5ldwp7CgoJbXkgJHNlbGYgPSBzaGlmdDsKCW15ICRk
YmggPSBDb25uZWN0X0RCKCkgb3IgcmV0dXJuOwoJbXkgJHRoaXMgPSB7ICdk
YmgnID0+ICRkYmggfTsKCWJsZXNzICR0aGlzLCAkc2VsZjsKCSR0aGlzOwp9
CgpzdWIgREVTVFJPWQp7CglteSAkdGhpcyA9IHNoaWZ0OwoJRGlzY29ubmVj
dF9EQigkdGhpcy0+eydkYmgnfSk7Cn0KCnN1YiBDb25uZWN0X0RCCnsKCglt
eSAkZGJuYW1lID0gJ3Rlc3RfZHZhbW9zJzsKCW15ICRkYnR5cGUgPSAnbXlz
cWwnOwoJbXkgJGRiaG9zdCA9ICdtZW50b3InOwoJbXkgJGRicG9ydCA9ICcz
MzA2JzsKCgkJCSMjIyMgc2V0IHVwIGhhbmRsZSAjIyMjCglteSAkZGJzdHIg
PSAiREJJOiRkYnR5cGU6JGRibmFtZTtob3N0PSRkYmhvc3Q7cG9ydD0kZGJw
b3J0IjsKCW15ICRkYmggPSBEQkktPmNvbm5lY3QoJGRic3RyLCAkdXNlciwg
JHB3LCB7CgkJUmFpc2VFcnJvciA9PiAwLAoJCUF1dG9Db21taXQgPT4gMAoJ
CX0pIG9yCglyZXR1cm4gJGRiaDsKfQoKc3ViIERpc2Nvbm5lY3RfREIKewoJ
bXkgJGRiaCA9IHNoaWZ0OwoJJGRiaC0+ZGlzY29ubmVjdCgpOwp9CgoKc3Vi
IFNRTF9RdWVyeQp7CglteSAkdGhpcyA9IHNoaWZ0OwoJbXkgJGRiaCA9ICR0
aGlzLT57J2RiaCd9OwoJbXkgJHN0YXRlbWVudCA9IHNoaWZ0OwoJbXkgJHN0
aCA9ICRkYmgtPnByZXBhcmUoJHN0YXRlbWVudCk7CglteSAkcmVzID0gJHN0
aC0+ZXhlY3V0ZShAXyk7CglyZXR1cm4gJHN0aDsKfQoxOwo=

--579699202-1654816860-1064595415=:627
Content-Type: text/plain; charset=us-ascii

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
--579699202-1654816860-1064595415=:627--

Re: broken DBD-mysql-2.9002 (fixed)

am 26.09.2003 18:58:51 von Wolfgang Friebel

How to clean up the user table before insert a new data in?

am 06.10.2003 02:51:13 von lei shen

Hi! Dose anyone know how to clean up a user table without drop a table in
sql?thanks

Brian Shen
----- Original Message -----
From: "Wolfgang Friebel"
To: "Rudy Lippan"
Cc: "Jochen Wiedmann" ;
Sent: Friday, September 26, 2003 12:58 PM
Subject: Re: broken DBD-mysql-2.9002 (fixed)

> On Fri, 26 Sep 2003, Rudy Lippan wrote:
>
> > That is right weird. Than you for the update -- I was just starting to
> > respond to the first message. It seems that the attachment got lost in
> > the forward, do you think that you could send it again.
> >
> >
> > > ####################
> > > # get_info()
> > > # Generated by DBI::DBD::Metadata
> > >
> > > sub get_info {
> > > my($dbh, $info_type) = @_;
> > > require DBD::mysql::GetInfo;
> > > my $v = $DBD::mysql::GetInfo::info{int($info_type)};
> > > $v = $v->($dbh) if ref $v eq 'CODE';
> > > return $v;
> > > }
> > >
> >
> > I don't see what could be causing the problem, offhand. BTA, the
existance
> > of get_info() changes the behaviour of DBI, but even so, what does any
of
> > that have to do with accesing a variable in another package? Maybe I am
> > missing something here as I have not seen code that causes the problem.
> >
> Indeed, we are the module still in many other scripts which all do work
> flawlessly (afaik).
>
> For completeness: The test script is
>
> #!/opt/products/perl/5.8.0/bin/perl
> use Db;
> Db::Init_DB();
> use Dumpvalue;
> $d=new Dumpvalue;
> $d->dumpValue(\%Db::);
>
> and the Module Db.pm is attached to this mail
>
> The output with get_info in place is just the ordinary variables:
> DBI Version: 1.37
> 'BEGIN' => *Db::BEGIN
> 'Connect_DB' => *Db::Connect_DB
> 'DESTROY' => *Db::DESTROY
> 'Disconnect_DB' => *Db::Disconnect_DB
> 'Init_DB' => *Db::Init_DB
> 'SQL_Query' => *Db::SQL_Query
> 'col_names_hash' => *Db::col_names_hash
> 'dbh' => *Db::dbh
> 'import' => *Db::import
> 'new' => *Db::new
> 'pw' => *Db::pw
> 'tables' => *Db::tables
> 'user' => *Db::user
>
> while without get_info all the variables that get created from the
> contents of the database are printed as well:
> DBI Version: 1.37
> 'BEGIN' => *Db::BEGIN
> 'Connect_DB' => *Db::Connect_DB
> 'DESTROY' => *Db::DESTROY
> 'Disconnect_DB' => *Db::Disconnect_DB
> 'Init_DB' => *Db::Init_DB
> 'SQL_Query' => *Db::SQL_Query
> 'account_filesystem_account_id_hash' =>
> *Db::account_filesystem_account_id_hash
> 'account_filesystem_filesystem_id_hash' =>
> *Db::account_filesystem_filesystem_id_hash
> 'account_filesystem_hash' => *Db::account_filesystem_hash
> 'account_hash' => *Db::account_hash
> 'account_mailinglist_hash' => *Db::account_mailinglist_hash
> .....
>
> Wolfgang

------------------------------------------------------------ ----------------
----

> --
> MySQL Perl Mailing List
> For list archives: http://lists.mysql.com/perl
> To unsubscribe:
http://lists.mysql.com/perl?unsub=lshen@pop900.gsfc.nasa.gov

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

How to clean up the user table before insert a new data in?

am 06.10.2003 02:51:13 von lei shen

Update: broken DBD-mysql-2.9002 (resolved)

am 13.10.2003 16:54:37 von Wolfgang Friebel

Hi,

a few days ago I wrote that variables that got dynamically created
from the contents of mysql tables were correct with an older mysql version
but did not work with the recent DBD-mysql-2.9002:

.... (With DBD-mysql-2.1027) (all dynamically created
variables are in place) where with the DBD-mysql-2.9002 version
all variables are missing that were created like in line 71 of Db.pm:

${$hn}{$hid}{$id} = ...

If we dump the variables in the package Db they are still existing and
filled correctly. They do not seem to be visible however outside through
fully qualified symbol table access.

I also wrote that the problem seemed to be related to the existence of the
(new) get_info subroutine. The fix I provided did work for us, but it was
not correct as I meanwhile found out, because the real reason for the
misbehaviour is a change in the DBD-mysql interface !!!

This becomes evident when comparing test scripts, e.g:
diff -r DBD-mysql-2.1027/t/akmisc.t DBD-mysql-2.9002/t/akmisc.t
461c461
< Test($state or (grep( /^$table1$/, @array )))
---
> Test($state or (grep( /^`$table1`$/, @array )))

Here the output of $dbh->listtables is processed. While the old output was
simply a list of ASCII strings the new output is quoted with backticks.

This is the real reason why our scripts stopped from working.

Conclusion: there is no error in DBD-mysql-2.9002, but there is also no
hint that the output of several functions has changed (at least I did not
get a clue from the ChangeLog)

Best regards
--
Wolfgang Friebel
Deutsches Elektronen-Synchrotron DESY | Phone: +49 33762 77372 |
Platanenallee 6 | Fax: +49 33762 77216 |
D-15738 Zeuthen Germany | E-Mail: Wolfgang.Friebel@desy.de |

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Update: broken DBD-mysql-2.9002 (resolved)

am 13.10.2003 16:54:37 von Wolfgang Friebel

Re: Update: broken DBD-mysql-2.9002 (resolved)

am 13.10.2003 19:17:26 von Rudy Lippan

On Mon, 13 Oct 2003, Wolfgang Friebel wrote:

> Conclusion: there is no error in DBD-mysql-2.9002, but there is also no
> hint that the output of several functions has changed (at least I did not
> get a clue from the ChangeLog)

It's a DBI thing. DBI is doing the quoting and not DBD::mysql... It is a
side effect of implementing get_info(); as soon as DBI noticed that it was
able to determine the quote character, DBI started quoting all returned
table names... Of course this also causes problems when running mysql in
ANSI mode where mysqld changes the quote char from '`' to '"' :(

Rudy

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: Update: broken DBD-mysql-2.9002 (resolved)

am 13.10.2003 19:17:26 von Rudy Lippan