[Openinteract-dev] SPOPS 0.72 (and 0.73) broken

[Ray Z. <rz...@co...>]

I'm back after some time off ...

First, I'm getting test 37 failing for t/30_dbi.t ...

not ok 37 - Field update (multiple object) execution
#     Failed test (t/30_dbi.t at line 260)
#          got: '2'
#     expected: '3'

... and a bunch of my ESPOPS tests (which work fine with SPOPS-0.70) 
still break. Let me respond to your previous e-mail on field_update() 
...

At 10:40 AM -0500 12/24/02, Chris Winters wrote:
>Ray Zimmerman wrote:
>>I think that's still wrong ... $rv = ( $rv != 0 ) was correct.
>
>But this removes information that might be useful: returning $rv 
>gives an indication of the number of rows affected while still 
>retaining the "return false if no rows affected" semantics. So you 
>can still do:
>
>  my $rows = $class->field_update( ... );
>  if ( $rows ) {
>      print "$rows rows affected";
>  }
>  else {
>      print "No rows affected";
>  }

If I understand things correctly, this code will not do what you 
expect. The problem is precisely that it doesn't retain the "return 
false if no rows affected" semantics. If no rows are affected $rows 
will be '0E0' which is a true value for which $rows == 0 is also true.

 From the DBI docs ...

"A successful execute always returns true regardless of the number of 
rows affected, even if it's zero"

... and ...

"For a non-SELECT statement, execute returns the number of rows 
affected, if known. If no rows were affected, then execute returns 
``0E0'', which Perl will treat as 0 but will regard as true. Note 
that it is not an error for no rows to be affected by a statement. If 
the number of rows affected is not known, then execute returns -1."

As it stands, I think field_update() always returns true, even if no 
rows were affected.

So, I still think the "$rv = ( $rv != 0 )" code from 0.70 is what we 
(or at least I :-) want.

>>>How were you retrieving/using the field types?
>>
>>I was calling $self->all_field_types() then checking types against 
>>constants defined in DBI.
>
>You should be able to use something like:
>
>  my $type_hash = $class->db_discover_types( $class->table_name );
>  foreach my $field ( keys %{ $type_hash } ) {
>      print "$field is DBI type $type_hash->{ $field }\n";
>  }
>
>SQLInterface->db_discover_types is still the front end for retriving 
>the types, and under the covers we're still using DBI types, just 
>getting them in a cleaner manner.

Ah ... whoops ... all_field_types() was an ESPOPS method that calls 
db_discover_types(), as you suggest, with the various classes/tables 
that make up an object with inherited fields.

However, it looks like db_discover_types() is now returning a 
SPOPS::DBI::TypeInfo object instead of a simple hash ... I never 
installed SPOPS-0.71 so I missed this change ... lemme go have a look 
at the docs for this class ...

... hey, the docs thank me for pointing out the need for the 
functionality in this module ... am I forgetting something or are you 
just starting to put my name in the credits out of habit :-)

So your example of how to use db_discover_types() is no longer valid, is it?

Shouldn't it be ...

  my $type_info = $class->db_discover_types( $class->table_name );
  foreach my $field ( $type_info->get_fields ) {
      print "$field is DBI type " . $type_info->get_type( $field ) . "\n";
  }

... maybe I missed it, but I didn't see a way to get back the old 
hash that my code was using. In any case, I can change my code to use 
the new TypeInfo object instead of the hash ... it's not a big 
problem.

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853