[Dbix-class] Can add_column be called on a Row?

[Peter Rabbitson]

On 10/04/2014 10:56 PM, Bill Moseley wrote:
>
>
> On Sat, Oct 4, 2014 at 12:04 PM, Peter Rabbitson <rabbit+dbic at rabbit.us
> <mailto:rabbit+dbic at rabbit.us>> 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;


The general answer is "yes". You can use whatever fits in your general 
development paradigm. Either a Moo(se) subclass, or a role (trait) or 
just use regular subclassing and add a Class::Accessor::Grouped-based 
accessor - anything really works.

And yes - adding a "virtual column" to only use it as a vehicle for 
extra metadata, unrelated to the underlying storage - that is indeed 
quite wrong.