Re: Caching of describeTable

> Hi Shahar
>
> It's a hairy one for sure! I've seen a lot of XML/config solutions
> whereby you 'synch' your class definitions with your database (or
> similar) to negate the need for frequent calls to determine the
> table/row structure. The current solution in Zend_Db_Table is definitely
> wasteful and I think it's where a lot of work is needed.
>
> I had toyed around an idea whereby you could manually describe your
> table structure within the class by defining certain properties, thus
> overriding the need for the describe() method. If it didn't exist when
> the class was instantiated then the default describe methods could be
> used and, as you say, it would be great if you could pass an instance of
> a cache to a DB adapter so that you could retrieve the definition locally.
>
> E.g.
>
> MyClass extends Zend_Db_Table
> {
>     protected $_name = 'mytable';
>     protected $_row = 'MyClass_Row';
>     protected $_schema = array('id' => array('type' => 'integer', 'null'
> => false),
>                                'name' => array('type' => 'text', 'null'
> => true),
>                                'description' => array('type' => 'text'));
>     protected $_primary = 'id'; // or could be array('name',
> 'description') for multi-key tables
> }
>
> Obviously a quick'n'dirty idea, but it demonstrates how a developer
> could easily maintain their tables and dispense with more weighty
> solutions. It could also be possible to point a config file for table
> definitions if desired, or to simply pass a $config instance.
>
> The reasoning behind this kind of 'manual' override is that despite some
> labour-intensive work by the developer in the first instance (manually
> tracking changes to table definitions and ensuring the class is
> up-to-date) it removes the need for all sorts of fancy (=intensive) ways
> of achieving the same end. If manual definitions are in place then it
> also allows for the developer to potentially create foreign key
> relationships, triggers, etc in pure PHP rather than necessarily rely on
> the DB engine (like MySQL 4.x MyISAM tables).
>
> But if you were more keen to use a 'live' schema then you could leave
> the $_schema property undefined and you could retrieve that information
> in a similar fashion to the present solution (although utilising the
> caching mechanism).
>
> The other instance I saw potential improvements was to allow each
> Zend_Db_Table class access to a registry of Db's so that each individual
> table instance didn't need to store an internal copy of the Db
> connection, bypassing the problems associated with serialised instances.
> In many (most?) cases the class really only accesses the database once
> to retrieve a row or rowset and then may only infrequently save back to
> the database if at all, so it seems unnecessary to store this
> supplementary information. At most you'd want to refer to a table
> structure from the row/rowset but that'd be it.
>
> Perhaps a Zend_Db_Scheme or Zend_Db_Registry helper class may be of use
> here?
>
> Anyhoo, look forward to your findings! Could you post them on the
> proposal as well as discussing ideas here so that we can track these
> ideas and comments?
>
> Cheers
>
>> Hi,
>>
>> Maybe I just need to RTFM but this one is a quickie: Is there a caching
>> solution for Zend_Db_Adapter_xxx::describeTable() ?
>>
>> That one gets called quite frequently, and is very unlikely to change in
>> production environemtns. Caching it somehow would be a smart idea.
>>
>> If nobody has suggestions, I'll do some hacking later and post an
>> article about it.
>>
>> TIA,
>>
>> Shahar.
>
> --
>
> Simon Mundy | Director | PEPTOLAB
>
> """ " "" """""" "" "" """"""" " "" """"" " """"" "  """""" "" "
> 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
> Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124
> http://www.peptolab.com
>
>
>