Re: set_sql

[prev] [thread] [next] [Date index for 2005/06/14]

> Can't bind a reference (EQ::machine=HASH(0xcb3d14)) at
> /home/goldstia/lib/DBIx/ContextualFetch.pm line 51.
>  at /home/goldstia/lib/DBIx/ContextualFetch.pm line 51
> ...
> EQ::machine_file->has_a('machine_key' => 'EQ::machine');
> EQ::machine_file->has_a('file_name_key' => 'EQ::file_name');
> ...
> The calling program looks like this:
>
> my $fobj = EQ::file_name->search('name'=>"/etc/hosts")->next;
> $fnk = $fobj->file_name_key;
>
> $mfo = EQ::machine_file->machine_file_latest($a->machine_key ,$fnk);

Since you have set up an has_a relationship on file_name_key, $fnk is an object reference which you're then passing to the SQL code.  You may have a similar problem with machine_key. Either one of the following should fix this:

1) Don't inflate file_name_key
     $fnk = $fobj->get('file_name_key');
     $mfo = EQ::machine_file->machine_file_latest($a->machine_key ,$fnk);

2) Or use the inflated object's id
     $fnk = $fobj->file_name_key;
     $mfo = EQ::machine_file->machine_file_latest($a->machine_key ,$fnk->id);

BTW, this is a common mistake and one of my CDBI pet peeves.  IMO, CDBI should be resolving CDBI object references the the value of their id.

     - Stepan

P.S.  I find it unfortunate that specifying a has_a relationship takes away "easy access" to the raw column value (you have to use get/set).  It would be nice if one could specify the accessor name for the has_a relationship.  This would allow you to access the underlying key value without having to call get() AND you could pick a relationship name that's something better than the underlying column name (i.e. "file_name" rather than "file_name_key":

EQ::machine_file->has_a('file_name_key' => 'EQ::file_name' =>
                        { accessor => 'file_name'} );

I can achieve something similar by writing a method instead of using has_a:

sub file_name {
    EQ::file_name->retrieve(shift->file_name_key);
}

But now CDBI doesn't know about the relationship (needed for has_many(), __JOIN(...)__, etc.)