[Catalyst] Instant CRUD with DBIC::Schema

[Peter Karman]

On 03/10/2008 07:14 AM, Zbigniew Lukasiak wrote:
> Hi Peter,
> 
> On Wed, Feb 20, 2008 at 7:48 PM, Peter Karman <peter at peknet.com> wrote:
>>  Also look at CatalystX::CRUD::Model::DBIC. Feedback appreciated.
>>
> 
> I had today another look at CatalystX::CRUD - it is promising, but I
> think there is too many indirection layers in it.  

I usually fault the other direction, so that's an interesting read.

For DBIC it
> requires configuration of both CatalystX::CRUD::Model::DBIC and
> CatalystX::CRUD::Object::DBIC.  I believe it could work with just one
> - for example CatalystX::CRUD::Model::DBIC where you could configure
> what methods on the object and how to call them to implement the
> needed interface.
> 
> Or perhaps you could all of it move to CatalystX::CRUD::Model and add
> configuration to interface it to DBIC and RDBO - they are not that
> different.
> 
> What do you think?  I believe some reduction of the number of modules
> used will simplify the whole thing.  

:) could be said for Catalyst in general...

> Maybe we could start the
> discussion with what you interface you need from the database model?
> 

My assumptions are:

1. CRUD is not just databases. I have a CatalystX::CRUD::Model::SVN and CatalystX::CRUD::Model::File
(the latter as part of the core CX::CRUD dist). I'm also going to be working on a ::LDAP
implementation, which is a database but not a SQL-based ORM type one.

2. The Model class interacts with many Objects. The Model searches and fetches, returning array or
iterator or count. The Object is singular. It creates/reads/updates/deletes one item (a db row, a
file, etc). I know that the DBIC ResultSet combines some of those features into one class, allowing
you to update/delete/etc multiple rows at a time. I find that less simple, conceptually, even if it
is more convenient to use. Simple is not always the same as convenient, in my book. Or otoh, a
simple user interface might well be convenient to the user, but a real pita (i.e. not simple) to the
developer who must implement it.

3. Users of a CX::CRUD::Model::* should not, in the common case, need to override or configure the
::Object class. It's there to implement the basic create/read/update/delete methods for the
Model-specific object. But it should be, for all practical purposes, invisible to the user. That's
why there is evil AUTOLOAD hackery in the base Model.

For a ORM like RDBO or DBIC, the Object class consists of easy pass-throughs to the appropriate
method on the delegate() object. But check out CatalystX::CRUD::Object::File for
one case where it is not so simple.

If you need to override the behaviour of the ::Object class for any given CX::CRUD::Model,
especially for an ORM, I suspect that it should really be overridden outside of Catalyst altogether,
in the delegate class. These are "thin" Models.

I do like the idea of simplifying. What I hear you saying is that getting rid of the Object class
would simplify things. I don't think it would. I think it would require mixing 2 different concepts
(the thing that gets objects, and the object itself). I tried to keep the API as high-level and
simple as I could. Individual implementations (like that for RDBO and DBIC) can get more complicated
because they have to implement an API that isn't necessarily like their own. I think of it like DBI
and the various DBD drivers.

That said, if you have specific changes you'd like to see, I'm open to persuasion. I'm just not
persuaded yet. :)

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