[Dbix-class] column accessor namespace

[Dave Howorth]

David Kamholz wrote:
> With the refactor in 0.05, this problem is much easier to solve.  There 
> is no already-written code to do exactly what you're talking  about, but 
> all the hooks are there. One thing you could do is just  not load the 
> DBIC components you don't want, so e.g. there would be  no belongs_to 
> helper provided by DBIC in your table classes.

This is fine until I _do_ want to use a component :)  I don't want to 
commit to a strategy that says I'm not going to use features.

<snip>
> __PACKAGE__->add_columns(foo => { accessor => 'foo_acc' }, bar =>  { 
> accessor => 'bar_acc' });
> 
> Obviously if you wanted to do this in a consistent way for every  
> column, you would want to write a wrapper method that called  
> add_columns for you. Relationships don't have to be named the same as  a 
> column, so you have full control over that from the start.
<snip>

This is the same as CDBI, I think, and is what I do at the moment.

> The most important innovation in 0.05, however, is not forcing a  class 
> to be several things at once as in CDBI. Every table class is  proxied 
> to an underlying table _object_, whose class is determined by  
> table_class (defaults to DBIC::ResultSource::Table). The table  method, 
> just a class data accessor in CDBI, is defined in  
> DBIC::ResultSourceProxy::Table (loaded by Core) and is worth studying  
> in some detail. Every table class has a result_source_instance, which  
> is the "real" object; the class is just a convenience. You will see  
> also that the result_source_instance has a result_class, which is the  
> class into which row objects will be blessed. This can be any class  you 
> want, and hence can have any methods defined on it that you want.  
> Finally, the result_source_instance has a resultset_class, which  
> defines methods like search, create, update, delete, and so on. This  
> can also be set to whatever you want.

This just goes whoosh over my head for now :) But it's probably the most 
relevant.

It was actually the first section in the doc

http://search.cpan.org/~mstrout/DBIx-Class-0.05000/lib/DBIx/Class/Manual/SchemaIntro.pod#Setup

that originally led to my question, because when it talks about 
result_source classes it says "My::Schema::Album will have albumid()" 
and "__PACKAGE__->belongs_to ..." which is exactly the situation I want 
to avoid.

Are you saying that this occurs because the result_class defaults to the 
result_source class? But it can be changed somehow? That would be promising.

Thanks, Dave