Re: Caching of describeTable

> As a first and simple step, I think that allowing the user to specify
> the table strcuture is a cheap and very nice to have option.
>
> Let's face it - I'd rather specify my table structure myself (which will
> almost never change in production) than having the class study it again
> and again - even if it's cached (That is only once every n requests).
>
> As a further solution, if I have time, I will try to find some simple
> caching solution for it.
>
> Shahar.
>
> Simon Mundy wrote:
>> 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
>>
>>
>>
>
>