[Zope-dev] ZTables and/or Catalog plugable brains?

[Casey Duncan]

On Thursday 04 October 2001 07:34 pm, Jay, Dylan allegedly wrote:
>
> I tried using ZClasses but it seems to run slow and take up space. Instead
> I'm  using Catalog (without ZCatalog) to contain the data. I'm presuming
> this will be quite efficient (comments welcome).

Yup that should be pretty efficient. Plus you can index and query the thing 
fairly easily.
>
> Now to my question, How do Catalog plugable brains work? I've looked but
> can't see what the brain class has to look like to work. My first attempts
> don't seem to work. The classes are created but don't contain the data. Is
> the record data passed into the constructor?

I'm not an expert on brains per se, but my understanding is that they allow 
you to wrap functionality from a particular class around data stored in a 
table (such as a Catalog or an external database) without making each record 
an instance of the class.

This is how, when the Catalog returns data, you get the getURL and getObject 
methods for each record (among others). TinyTable and Z SQL Methods also 
support this functionality, and it is exposed in the management interface.

This would allow you to store the actual data as regular metadata elements in 
the Catalog, and get objects out when you query it. It would avoid storing 
the data twice, once in the objects and again in the metadata and all of the 
disadvantages this causes in terms of storage and synchronization.

>
> Also in my searches I came across lots of references to something called
> ZTables. This seems to be a Catalog with a UI that is about lots of tabular
> information (rather than a ZCatalog which is specialized to replicating and
> indexing existing objects). Is this dead? If not where is it? If so, why?

AFAIK, Catalog contains the only remaining remnants of ZTables in Zope. 

> It seems like a really good idea to me. It seems to be there are times when
> objects (esp ZClasses) are too heavy?

ZClasses impose a performance penalty due to their inherent complexity and 
overhead. You would do much better creating a straight Python class for 
applications where performance and overhead per record is an issue.

I personally avoid using ZClasses for everything but the simplest custom 
objects.

>
> Anyone with comments about how ZPatterns fits into all of this would also
> be welcome.

My understanding is that ZPatterns is for abstracting the application from 
the storage. It is most beneficial for creating storage-independent 
applications. It would benefit you if that is a requirement, no so much if 
not.

An example might be an application with data in objects, catalogs and 
external databases. ZPatterns would let you create an abstraction layer so 
that the application would not need to be aware of where any given piece of 
data was coming from. You could therefore change your data storage later and 
ideally you would only have to change the abstraction layer, not the 
application itself.

/---------------------------------------------------\
  Casey Duncan, Sr. Web Developer
  National Legal Aid and Defender Association
  c.duncan@nlada.org
\---------------------------------------------------/