Can add_column be called on a Row?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Can add_column be called on a Row?

Bill Moseley
I'm upgrading DBIC on a project and it's helping to find bugs in our code.

Running tests I found an error ("No such column 'last_saved') and then found this code:


    my $last_saved_column_data = {
        data_type     => 'timestamp with time zone',
        default_value => 'now()',
        is_nullable   => 1,
        size          => 8,
    };

    foreach ( $users_rs->all ) {

        $_->add_column( 'last_saved' => $last_saved_column_data );
        $_->set_column( 'last_saved' => $column_value );
    }

I assume what the programmer wanted to do there was just add an attribute "last_saved" to the Users result class.   Or maybe only to those specific rows returned in that resultset (e.g. as a singleton method).

Apparently that was working in the past.   Was that ever a supported behavior?


--
Bill Moseley
[hidden email]

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: Can add_column be called on a Row?

Bill Moseley


On Sat, Oct 4, 2014 at 12:04 PM, Peter Rabbitson <[hidden email]> wrote:

The problem in its core (and this has always been the case) is that:
  My::App::Schema::Result::Foo->result_source_instance
    !=
  My::App::Schema->source('Foo')
    !=
  $my_app_schema_instance->source('Foo')

The change in 4006691d207 makes things consistently work on the "current instance level", whereas before it was not entirely clear where the ResultSourceProxy call will actually land.

Does this answer your question? Is there something I missed when implementing this part?

That answers my question -- I don't think it makes sense to call add_column on a row object, which is what our code was doing.   I don't know why they (meaning our developer) used this approach instead of just adding additional attribute's the the result class -- or perhaps creating a subclass with the extra attributes.

Is that the suggested approach now?  If you have a result class for, say,  "Employee" and you wanted to add meta data (meaning associated attributes that are not stored in the database) for only a subset of Employees that are "retired" is this still the way to go?

That is something like:

package Employee;
use base 'DBIx::Class::Core';
__PACKAGE__->table( 'employee' );
__PACKAGE__add_columns( ... );
...
1;


package RetiredEmployee;
use Moose;
extends 'Employee';
__PACKAGE__->table( 'employee' );
__PACKAGE__->source_name( 'RetiredEmployee' );

has current_age => ( ... );  # for lack of a better example.

1;




--
Bill Moseley
[hidden email]

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...