Re: Zend_Db_Table

Abu Hurayrah-2 wrote:
  

 From your message, it seems like you're making a distinction between 
ORM & KISS - my understanding was that ORM (Object-Relational Mapping) 
is an implementation of KISS (Keep it Simple, Stupid!) (I don't know if 
there is a more PC term for it, so forgive my bluntness).  KISS isn't 
really a set standard, just a guideline to follow, and it seems to me 
that ORM follows the KISS mentality.  Maybe someone can clarify this for 
me...?


    

Sorry for the confusion - I was a little unclear. I meant a comprehensive
ORM system (in a Ruby on Rails vain) .vs. a more lightweight (KISS) approach
that doesn't try to take over control of *everything*. I personally prefer
the flexibility of the second approach.

However, the above is my main problem with the framework as it stands. There
don't seem to be any usable base classes to extend a model from. The
Zend_Db_Table classes are adequate if your tables map nicely to your domain
objects in a 1:1 ratio but go any further than this and you find yourself
wrestling with overriding (and breaking) existing base classes.

At the moment, I see no nice way of extending the Zend_Db_Table class to use
as a model to, say, represent a list of articles (from an articles table)
with extra author information linked from a secondary authors table. The
only way (that I can find) is to either extend the base functionality (in
messy, framework incompatible ways) to allow for joins within the select
population OR adding functionality to have an authors object as a child of
articles (which then involves doing N extra queries for any given list of
articles which isn't practical).

I realise that what I am trying to do above isn't, I assume, what the
Zend_Db_Table* classes were designed for which is fair enough. However, I
think many would like to see some form of back end for model representation
without having to write their own from scratch. 

Believe me, you're not the only one grappling with this same issue.  The ORM changes will be very welcome.  In particular, as you've pointed out, trying to extend the base objects - be it Zend_Db_Table, Row, or Rowset - is a real pain, and frequently requires a lot of wet (as opposed to DRY- Don't Repeat Yourself) code.  To make Zend_Db_Table return a custom extended Row or Rowset class rather than then built-in ones requires rewriting no less than 3 functions, usually just to change one call.  Anyway, I'm sure these changes are in the pipeline, and I don't like to gripe without a solution in hand, and I simply have had the time to post anything better yet.

The other major change I would like to see is for Zend_Db_Table_Rowset to implement the ArrayAccess interface, but I simply haven't had the time to do it myself, so I don't mention it either, too much.