« Return to Thread: Caching of describeTable

Re: Caching of describeTable

by Simon Mundy :: Rate this Message:

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.

« Return to Thread: Caching of describeTable