[Dbix-class] column accessor namespace

[David Kamholz]

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. But  
assuming you want to include everything in Core, there are some other  
things you can do. For example, instead of doing this:

__PACKAGE__->add_columns(qw/ foo bar /);

You could do:

__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. You can  
also choose not to have an accessor created for them and just use  
search_related and other such functions to which you pass the name of  
the relationship.

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.

The ResultSetProxy and ResultSourceProxy classes take care of making  
things work the way CDBI and earlier DBIC users expect. Take a look  
at them if you want to get an idea of how the new internals fit  
together.

In the coming weeks there will no doubt be a lot of good suggestions  
from people as to how to more easily extend and customize all this,  
once there is a feeling for what sorts of things are useful to do.  
But all the stuff is already there.

Hope this helps,
Dave