[CDBI] Help tracking down a problem w/ has_a and unexpected deflating.

[prev] [thread] [next] [Date index for 2005/08/28]

From: George Hartzell
Subject: [CDBI] Help tracking down a problem w/ has_a and unexpected deflating.
Date: 23:30 on 28 Aug 2005
I'm building a Mason based web app on FreeBSD 6-ish using perl 5.8.6
and a whole passel of cpan-standard stuff (details if they're
interesting).  I'm using SQLite to store my data and Class::DBI to
manipulate it.  I'm using Class::DBI version 0.96 built via FreeBSD's
ports system but see similar results with a copy of 0.999.

I'm using DateTime to play with dates, and as I was getting started I
just stuff them into SQLite STRING columns via DateTime->now().

I've been actually working on the date/time stuff now, and have
switched over to storing seconds since the epoch in the DB tables
(via DateTime->now->epoch()) and have been trying to use Class::DBI's
has_a and inflate to convert the from the epoch's to DateTime's.
Here's my Project.pm class (with a couple of useless functions
elided).

    package DNASeqr::DB::Project;
    use strict;
    use warnings;
    
    use base qw(DNASeqr::DB::DBI);
    our $VERSION = 0.01;
    
    __PACKAGE__->table('project');
    __PACKAGE__->columns(All => qw/project_id/);
    __PACKAGE__->columns(Essential => qw/name
    				     seq_request
    				     started_on
    				     ended_on
    				     comment
    				     /);
    
    __PACKAGE__->has_a(seq_request => 'DNASeqr::DB::SeqRequest');
    __PACKAGE__->has_a(started_on  => 'DateTime',
    		   inflate => sub {DateTime->from_epoch(epoch => shift);});
    __PACKAGE__->has_a(ended_on  => 'DateTime',
    		   inflate => sub {DateTime->from_epoch(epoch => shift);});
    __PACKAGE__->has_many(samples => 'DNASeqr::DB::Sample');
    __PACKAGE__->has_many(primers => 'DNASeqr::DB::Primer');
    __PACKAGE__->has_many(oligo_orders => 'DNASeqr::DB::OligoOrder');
    
    # some unrelated subs were deleted here....
    
    1; #this line is important and will help the module return a true value
    __DATA__
    
    CREATE TABLE project (
    	project_id	INTEGER PRIMARY KEY,
            seq_request     INTEGER REFERENCES seq_request(seq_request_id),
    	name		STRING,
    	started_on	STRING,
    	ended_on	STRING,
    	comment 	STRING
    );	

I think that it works as I'd expect, although I saw one instance of
my particular problem, but I'd been single stepping through the
Class::DBI code and may have fubar'ed something myself.

I cut and pasted the has_a line into my other date using classes, and
it seems to work for everything except one class.  In particular, if I
look at the database via the sqlite command, the date columns have
values that are nice looking integers, and converting from them into
a DateTime and printing them out yields reasonable results.

One class, OligoOrder.pm, included here has a problem.
    
    package DNASeqr::DB::OligoOrder;
    use strict;
    use warnings;
    
    use base qw(DNASeqr::DB::DBI);
    
    use Bio::Seq;
    use Bio::SeqFeature::Generic;
    
    our $VERSION = 0.01;
    
    __PACKAGE__->table('oligo_order');
    __PACKAGE__->columns(All => qw/order_id/);
    # by calling *all* of the columns essential, we avoid the lazy loading stuff.
    __PACKAGE__->columns(Essential => qw/project
    				     name
    				     seq
    				     ordered_on
    				     /);
    __PACKAGE__->has_a(project => 'DNASeqr::DB::Project');
    __PACKAGE__->has_a(ordered_on  => 'DateTime',
     		   inflate => sub {DateTime->from_epoch(epoch => shift);});
    
    
    1; #this line is important and will help the module return a true value
    __DATA__
    CREATE TABLE oligo_order (
          order_id         INTEGER PRIMARY KEY,
          project          INTEGER REFERENCES project(project_id),
          name             STRING,
          seq              STRING,
          ordered_on       STRING
    );
    
Values in the ordered_on column end up looking like
'2005-08-28T23:19:17' (which is DateTime's default stringification).

I've stepped down into the Class::DBI code and it seems that
OligoOrder.pm has a deflator that's being called that does the
conversion, but I can't figure out why it's happening.  The scalar
holding the value is a nice clean integer all of the way down.  More
confusingly, why is it happening here, but not in my other classes
(having cut and paste the same has_a lines and then touched up the
column names?)

Worse yet, it seems to be a heisenbug, for a couple of moments (while
running in the debugger) I've seen reasonable values in the OligoOrder
table and I've seen one bad value in the Project table (also whilst
poking in the debugger.

I've tried changing the column type to INTEGER (which it will
ultimately be), but it doesn't seem to fix anything.  The date columns
are still STRINGs in the other tables, so I'm leaving it that way for
the moment until I figure this out.

If I remove the has_a for the ordered_on column, then the values
stored in the db are appropriately valued integers.

I'm at a loss as to where to look next, I don't understand how to
figure out why I'm getting the deflator....

Any help, suggestions, and/or pointers would be welcome. 

g.

_______________________________________________
ClassDBI mailing list
ClassDBI@xxxxx.xxxxxxxxxxxxxxxx.xxx
http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi

[CDBI] Help tracking down a problem w/ has_a and unexpected deflating.
George Hartzell 23:30 on 28 Aug 2005

Generated at 14:27 on 07 Sep 2005 by mariachi v0.52