[Catalyst] Instant CRUD with DBIC::Schema

[Peter Karman]

On 03/12/2008 11:39 AM, Zbigniew Lukasiak wrote:
> On Wed, Mar 12, 2008 at 5:06 PM, Peter Karman <peter at peknet.com> wrote:
>>
>>  On 03/12/2008 10:27 AM, Zbigniew Lukasiak wrote:
>>
>>  > If you'd make them to use the same db connection than indeed this
>>  > would be like the ModelAdaptor. But then again you should have just on
>>  > adaptor per model type - not per table (for models with tables).
>>  >
>>
>>  certainly if you think CX::CRUD::Model::DBIC should be implemented that way, I encourage
>>  you to do so. The RDBO approach is 1class=1table, so the RDBO Cat Model follows that. All
>>  the classes can share (or not) a single DBI connection; that's up to how the underlying
>>  RDBO classes are configured. The db connection information is not part of
>>  CX::CRUD::Model::RDBO. It is only the DBIC model that requires that information. RDBO uses
>>  a separate class (Rose::DB) to implement DBI handle management, and that information is in
>>  the (non-Catalyst) RDBO classes.
>>
>>  CX::CRUD::Model is completely agnostic about storage, connections, etc. It's up to the
>>  implementation to handle that part.
>>
> 
> You see - in fact in DBIC you still have the same 1table = 1class
> thing - but the difference is that the model is the whole database not
> just one table.  And the catalyst model is an adaptor for the whole
> model not just for one table - this way you keep all the business
> logic in the model and the adaptor is only for wrapping - and also you
> don't need to create wrappers for each table (which would be a cut and
> paste excercise).
> 

for DBIC, Catalyst::Model::DBIC::Schema is an adaptor for the whole DBIC model. But RDBO
has no equivalent for the entire database. ::DBIC::Schema has a mechanism for getting at
the individual tables. The RDBO approach is just different.

There is a wrapper for each RDBO table, but they are very minimal, and allow for
per-table/class customization that the underlying RDBO class might not have (like
load_with for example).

This is a difference in design philosophy. The question is: At what level of granularity
does the Cat Model interface with the underlying model. Because CX::CRUD is concerned with
Forms, I have chosen a granularity of 1table=1model, based on the assumption that
1form=1table (for ORM-style models).

Of course, the Real World has forms that represent multiple tables or parts of tables, and
so the simplicity of CX::CRUD will start to be stretched. But that's why it is implemented
as subclass-able components. I've had forms that represent objects spanning multiple
tables via FKs and other relationships, and have found CX::CRUD-style components up to the
task.

> 
>>  >>  If you like the model_adaptor() syntax in the Controller API, how would you implement a
>>  >>  ModelAdaptor class and how would you change the Controller API to use it?
>>  >>
>>
>>  You've left this part of my email unanswered... :)
>>

eh-hem.

-- 
Peter Karman  .  peter at peknet.com  .  http://peknet.com/