Re: stopping numification

[prev] [thread] [next] [Date index for 2005/05/25]

On 25 May 2005, at 11:47, Simon Wistow wrote:

> On Tue, May 24, 2005 at 01:13:58PM -0400, Christopher Laco said:
>
>> http://use.perl.org/~hex/journal/24191
>>
>
> Bizarrely I helped Earle work on that. My brain is clearly not  
> working.
>
> So, I've put
>
> __PACKAGE__->data_type(version => DBI::SQL_BLOB); [0]
>
> as per
>
> http://www.spanner.org/lists/cdbi/2004/09/27/36d1909a.html
>
> and
>
> http://wiki.class-dbi.com/index.cgi?WorkingWithBlobs
>
>
> and ... nada. Doesn't make a blind bit of difference. This with the
> latest versions of everything :(

I can reproduce the problem with a simple test case, but it doesn't  
seem like Class::DBI is to blame.

Scattering warnings around cdbi gives this:

cdbi::_create: data->{title} is 1.0
cdbi::_create: real->{title} is 1.0
cdbi::_insert_row: data->{title} is 1.0
cdbi::_insert_row: data->{title} is 1.0    # immediately before $sth- 
 >execute(values %$data)
cdbi::_create: self->{title} is 1.0        # before reloading new  
object from database
cdbi::_create: self->title is 1            # after reloading new object
new object: $VAR1 = bless( {
                  'title' => '1',
                  'id' => 22,
                  'description' => undef
                }, 'My::Artist' );

so the bound value is definitely '1.0' but the stored value is '1',  
and it must be something that happens in DBD::SQLite. This is  
confirmed by the dbi-trace, i think:

     -> execute for DBD::SQLite::st (DBIx::ContextualFetch::st=HASH 
(0x1903b80)~0x190a7d8 undef '1.0') thr#1800400
sqlite trace: bind into 0x190a7c0: 1 => undef (0) pos 0
at dbdimp.c line 446
sqlite trace: bind into 0x190a7c0: 2 => 1.0 (0) pos 2
at dbdimp.c line 446
sqlite trace: Execute returned 0 cols
at dbdimp.c line 394

and the same test run against a mysql database works as it should.

if I were you I would seriously consider sprintfing your version  
number :)

will


ps. cdbi seems to assume that having called keys %foo you can call  
values %foo and get them in the same order. is that so? Nice  
shortcut, then.





>
> Having talked to Earle it seems that this might be a problem somewhere
> with Class::DBI - it works fine for him using plain old DBI and I can
> insert the value manually using dbish which *seems* to point the  
> finger
> at Class::DBI (or Class::DBI::SQLite).
>
> Simon
>
> [0] also tried SQL_BINARY and SQL_CLOB. And I've tried setting the  
> type
> in the SQL create statement as every combination of CLOB, TEXT,  
> VARCHAR
> and BINARY.
>
>
>