[Catalyst] Instant CRUD with DBIC::Schema

Zbigniew Lukasiak zzbbyy at gmail.com
Wed Mar 12 18:24:31 GMT 2008


On Wed, Mar 12, 2008 at 7:04 PM, Peter Karman <peter at peknet.com> wrote:
>
>
>  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.
>

You still can have just one Catalyst model class that would work as
adaptor for all of the individual RDBO table classes.  As you say the
adaptor should be minimal so it does not make sense to have separate
adaptor classes for each table. But you can have multiple instances of
the adaptor to keep the table names in it so that it could choose the
right RDBO table class.

But this is indeed a design decision.

>  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.
>

We are closing to it.  Basically the adaptor needs to store the table
name in it's instance - that's all.


>  --
>
>
> Peter Karman  .  peter at peknet.com  .  http://peknet.com/
>
>
>  _______________________________________________
>  List: Catalyst at lists.scsys.co.uk
>  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>  Dev site: http://dev.catalyst.perl.org/
>



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/



More information about the Catalyst mailing list