Chas. Owens schrieb:
The URL for the bug report is 
https://rt.cpan.org/Ticket/Display.html?id=118207&results=52bad5c05e442e5750731e7011056012

Thank you very much!

I resorted to use an integer instead of a bitfield,
and it works fine with things like


... SET `status` = `status` + 32 WHERE (NOT (`status` & 32)) AND foo ...


I´m not sure what might happen if endianess ever changes, though.


On Sat, Oct 1, 2016 at 11:44 AM Chas. Owens <chas.ow...@gmail.com 
<mailto:chas.ow...@gmail.com>> wrote:

    Poking around in the source, it does not appear to be well tested WRT bind 
variables (see the test file below).  I will file a bug at 
https://rt.cpan.org/Public/Dist/Display.html?Name=DBD-mysql but I wouldn't hold 
my breath on seeing anything other than a documentation change.  There is 
probably too much code in the darkpan that counts on the current behavior (ie 
making it sensible would break existing code that expects it to be broken).

    use strict <https://metacpan.org/source/strict>;
    use warnings <https://metacpan.org/source/warnings>;

    use Test::More <https://metacpan.org/source/Test::More>;
    use DBI <https://metacpan.org/source/DBI>;
    use vars <https://metacpan.org/source/vars> qw($test_dsn $test_user 
$test_password);
    use lib <https://metacpan.org/source/lib> '.', 't';
    require 'lib.pl <http://lib.pl>';

    sub VerifyBit ($) {
    }

    my $dbh;
    my $charset= 'DEFAULT CHARSET=utf8';

    eval {$dbh = DBI->connect($test_dsn, $test_user, $test_password,
    { RaiseError => 1, AutoCommit => 1}) or ServerError() ;};

    if ($@) {
    plan skip_all => "no database connection";
    }
    else {
    plan tests => 15;
    }

    if (!MinimumVersion($dbh, '4.1')) {
    $charset= '';
    }

    ok $dbh->do("DROP TABLE IF EXISTS dbd_mysql_b1"), "Drop table if exists 
dbd_mysql_b1";

    ok( $dbh->do('CREATE TABLE dbd_mysql_b1 (b BIT(8))') );

    ok ($dbh->do("insert into dbd_mysql_b1 set b = b'11111111'"));
    ok ($dbh->do("insert into dbd_mysql_b1 set b = b'1010'"));
    ok ($dbh->do("insert into dbd_mysql_b1 set b = b'0101'"));

    ok (my $sth = $dbh->prepare("select BIN(b+0) FROM dbd_mysql_b1"));

    ok ($sth->execute);

    ok (my $result = $sth->fetchall_arrayref);

    ok defined($result), "result returned defined";

    is $result->[0][0], 11111111, "should be 11111111";
    is $result->[1][0], 1010, "should be 1010";
    is $result->[2][0], 101, "should be 101";

    ok ($sth->finish);

    ok $dbh->do("DROP TABLE dbd_mysql_b1"), "Drop table dbd_mysql_b1";

    ok $dbh->disconnect;


    On Sat, Oct 1, 2016 at 11:34 AM Chas. Owens <chas.ow...@gmail.com 
<mailto:chas.ow...@gmail.com>> wrote:

        Whoops, meant to include links for the docs to those two functions:

        http://perldoc.perl.org/functions/pack.html
        http://perldoc.perl.org/functions/vec.html

        On Sat, Oct 1, 2016 at 11:31 AM Chas. Owens <chas.ow...@gmail.com 
<mailto:chas.ow...@gmail.com>> wrote:

            DBD::mysql is treating 1 and 3 as their ASCII values on insert due 
to quoting.  You need to create values that are bit fields themselves.  This 
being Perl, there are lots of ways of doing that:

            $dbh->do("create table bittest (lilbits bit(8))");

            my $insert = $dbh->prepare("insert into bittest values (?)");
            my $select = $dbh->prepare("select * from bittest where lilbits = 
?");

            $insert->execute(pack "n", 5);
            $insert->execute(pack "b", "101");

            vec(my $bitstring, 0, 8) = 5;

            $insert->execute($bitstring);

            $select->execute(5);

            while (my $row = $select->fetch) {
                     printf "%08b\n", ord $row->[0];
            }

            The first two use the pack function to pack the input into a binary 
representation (n converts integers, b converts strings of 0s and 1s).  The 
third uses the vec function as an lvalue to build a bitstring.  Interestingly, 
selecting with bitstrings doesn't seem to work and you have to use the number.  
I am not sure if this is a bug or not.  The inconsistent behavior for select 
and insert is certainly surprising enough that I would expect it to be 
mentioned in the docs, but I didn't see it.

            On Sat, Oct 1, 2016 at 10:35 AM hw <h...@gc-24.de 
<mailto:h...@gc-24.de>> wrote:


                Hi,

                what´s the correct way with DBI to update a field in a mysql 
database
                when the field type is 'bit'?

                I´m getting, for example, converted to integer, 53 instead of 3 
into
                the field.

                It goes like this:


                my $sth = $dbh->prepare("INSERT INTO t (`status`) VALUES (?)
                                           ON DUPLICATE KEY UPDATE `status` = 
?");

                $sth->execute(($var eq 'x' ? 1 : 0), ($var eq 'x' ? 3 : 0));


                That should work just fine but doesn´t in that the wrong bits 
of the
                field are being set.

                Is this a bug or a feature?

                --
                To unsubscribe, e-mail: beginners-unsubscr...@perl.org 
<mailto:beginners-unsubscr...@perl.org>
                For additional commands, e-mail: beginners-h...@perl.org 
<mailto:beginners-h...@perl.org>
                http://learn.perl.org/




--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to